Welkom

Welkom op de site van DE BRUIJN Project Support B.V.

Op deze site, vind u alles over efficiënt en praktisch Software Testen, en in onze shop vindt u producten die u kunt downloaden en direct gebruiken alsmede onze diensten.

DE BRUIJN Project Support richt zich sinds 1992 op het verbeteren van de Software Kwaliteit, door ondersteuning van onze klanten bij alle aspecten van Software Testen, zoals:

  • Software Test Management
  • Software Test Planning
  • Software Test opleiding (ITSQB, Tmap, ISO9126)
  • Software Testen (uitvoering)
  • Software Selectie
  • Implementatie van Software Pakketten
  • Checklists voor een snelle start
  • Voorbeelden en templates voor software testen

Wij bieden u besparingen in Software testen door u een praktische aanpak te bieden voor software testen met de volgende principes:

  • “Risk Based Software Testing”, omdat volledig testen van software niet mogelijk is.
  • Doen, tijdens de cursus / opleiding
  • Training tijdens het project (coaching)
  • No Cure, No Pay, voor onze workshops
  • “Niet goed, geld terug” garantie voor de download producten.
  • “Lean and mean”
  • Concrete producten, die u in de shop kunt bekijken en bestellen:
    • Checklists en templates, klaar voor download
    • Opleidingen en workshops, waarvan u de de passende samenstelling kunt kiezen en vervolgens kunt bestellen of een offerte kunt aanvragen
Geplaatst in Tmap, ISTQB, ISO9126-ISO25010 Getagd met ,

Agile en Scrum software testing

Werken in een Scrum of Agile aanpak vereist een kortere cyclus tussen definitie (user-story) en het uitvoeren van de software testen.

Hieronder laten wij u zien hoe die cyclus versneld kan worden, en hoe u besparingen kunt bereiken.

Uitdagingen voor Software Testen in een Scrum of Agile project

Met de steeds korter wordende cycli van software ontwikkeling komt in de praktijk het testen van de in een sprint opgeleverde functionaliteit vaak onder druk te staan.
Daarnaast lijkt het of de verworvenheden uit de meer traditionele ontwikkel en test aanpak bij Agile niet meer toepasbaar zijn. Denk hierbij aan het V-model.

Niets is volgens ons minder waar. Het V-model is ook toe te passen op korte cycli (User Story – Sprint). Echter dan zijn er wel hulpmiddelen nodig om de keten van Requirements (User Story) tot en met testen te versnellen.

Aanpak met BenderRBT

BenderRBT is gebaseerd op Risk en Requirements Based Testing (RRBT).

De Requirements (User Story) worden vastgelegd in een Cause Effect Graph (Oorzaak Gevolg Diagram). In dit geval van een koffieautomaat.

Cause Effect Graph Koffie automaat

Cause Effect Graph Koffie automaat

Iedere Actie of Status wordt een Node (knoop), met bijbehorende logica. Zo zal er alleen spanning beschikbaar zijn, als de stekker erin zit en de knop in “Aan” staat.
Dit principe geldt voor het hele schema, waarbij voor iedere Node in de True of False situatie moet worden afgehandeld in de logica en vervolgens moet worden getest.

Dit triggert echter de volgende vragen tijdens de evaluatie met de opdrachtgever. De volgende vragen rijzen:

  • Wat doen we als er geen heet water is ?. In dit geval hoort er een melding “TempLaag” te komen op de False status van “HeetWater”.
  • Kunnen de selectieknoppen voor de Koffiesoort (Zwart, Suiker, Melk, etc) tegelijk worden ingedrukt (fysiek), of is er sprake van “Radio-Buttons”. In dit geval hebben we een scherm met “Radio-Buttons”, dus wordt er een “One – Constraint” aangebracht, zodat geen testgevallen worden gegenereerd, die niet uitvoerbaar zijn.

Vervolgens garandeert BenderRBT, dat bij het aanmaken van de testen, iedere Node in True en False wordt getest (tenzij we Constraints hebben aangebracht)

Als één van de rapporten is de “Functional Specification” beschikbaar.

Functional Specification (gegenereerd uit de CEG) van de Koffie Automaat

Functional Specification (gegenereerd uit de CEG) van de Koffie Automaat

Hierboven staat de omschrijving van de Nodes in pseudo code beschreven. Een extra hulpmiddel om het model te valideren en vervolgens bij programmering te gebruiken.

Het volgende analyse rapport is de “Definition Matrix”

Beslissingstabel, tevens alle gegeneerde testgevallen

Beslissingstabel, tevens alle gegeneerde testgevallen

Deze tabel toont de gegenereerde testgevallen in een compacte vorm. Dit is de minimale testset, die alle Nodes in True of False test. (tenzij er Constraints zijn toegepast)

Ook dit overzicht wordt gebruikt voor validatie van het opgestelde model. Hier wordt meestal duidelijk dat er testen gaan ontstaan, die niet kunnen. Dat komt doordat er nog fouten zitten in de logica (AND, OR, XOR etc) of dat er onvoldoende aandacht is besteed aan Constraints.

Wij gebruiken de volgende proces stappen met BenderRBT in Agile / Scrum ontwikkeling en testen:

Stap 1. Eerste schets maken samen met de klant, de logica vastleggen

Cause Effect Graph Koffie automaat

Cause Effect Graph Koffie automaat

Stap 2. Met behulp van de Neon functie kunnen we (samen met de opdrachtgever) de scenario’s van de User-Story aanblikken. We hebben nu de mogelijkheid om een functioneel prototype te beoordelen. Op deze wijze wordt het testen geïntegreerd in het ontwerp.

Dit kunnen meer scenario’s zijn, dan de gecomprimeerde minimale testset (zie Definition Matrix)

Validatie van de logica, door condities in zelf True en False te zetten.

Validatie van de logica, door condities in zelf True en False te zetten.

Stap 3. Ready voor Sprint / begroting.

Na analyse van de rapporten wordt de logica “afgetekend” en een begroting van de inspanning gemaakt:

  • Voor iedere Node kan afhankelijk van het type (Input, DB access, etc) een aantal punten / uren worden toegekend voor de realisatie
  • De begroting van de testinspanning kan worden gemaakt aan de hand van het aantal uit te voeren testen en hun complexiteit (aantal stappen en typen invoer en uitvoer)

Stap 4. Testuitvoering.

Alle informatie voor de testuitvoering is beschikbaar, hetzij in vorm van de Definition Matrix  dan wel als uitgeschreven testcases, die aan de tester(s) kunnen worden uitgereikt.

Gegenereerd testscript

Gegenereerd testscript

Vervolgstappen:

  • Bepalen van de testen met de hoogste functionele dekking. BenderRBT garandeert een 100% functionele dekking (van het ingebrachte model). Echter tijdsdruk kan betekenen dat niet 100% van de testen kunnen worden uitgevoerd. Er zijn meerdere functies beschikbaar om de coverage te optimaliseren.
  • Bevriezen en opslaan van de huidige versie. Op deze wijze kan bij regressie testen beoordeeld worden
    • welke bestaande testen nog bruikbaar zijn,
    • welke nieuw gegenereerde aanvullende testen noodzakelijk zijn voor de 100% dekking.

Voordelen voor Agile en Scrum aanpak:

  • Validatie direct mogelijk door de designer, doordat verschillende representaties van de User-Story worden getoond.
  • Direct te gebruiken in overleg met de opdrachtgever (logisch prototype)
  • Hulpmiddel bij de ontwikkeling (exacte specificatie)
  • Testen zijn direct beschikbaar
  • Testinspanning eenvoudig te begroten, doordat het aantal testgevallen al tijdens specificatie van de User-Story bekend is.
  •  Tijdsbesparing, doordat maar 1 keer gespecificeerd hoeft te worden

NB. In de plaatjes die op deze pagina zijn gebruikt, zijn bewust fouten en ommissies gemaakt. Die zijn nodig om hier de discussie te verfijnen. Indien u (of uw klant) een commentaar / verbetering aanbrengt, wordt u “eigenaar”  van de specificatie. En dat is precies wat de doelstelling is.

Wilt u zelf ondervinden hoe deze aanpak werkt voor Agile en Scrum, wij helpen u graag verder, net als vele andere klanten.

Geplaatst in Scrum, Agile, Requirements Based Testing, Geen categorie Getagd met , , , ,

Efficient testen, kosten van ontwikkelen van testcases

Testen kost tijd en dus ook geld dat terugverdiend moet worden uit de afdekking van risico’s. Het is dus de kunst om de kosten van het software testen te minimaliseren.

Grofweg zijn de volgende benaderingen mogelijk bij de reductie van de test kosten:

  • Niet testen, indien dat uit oogpunt van risico afdekking acceptabel is.
  • Testaanpak bepalen op basis van de PRA (Product Risico Analyse). Daarbij wordt bewust een aantal aspecten minder dekkend getest en het aantal testen gereduceerd. Van belang is dat de testcoverage inzichtelijk moet worden gemaakt voor het nemen van een G0-Life beslissing.
    (hierover is voldoende informatie vrijelijk beschikbaar)
  • Offshoring van het testen, hetgeen mogelijk moet zijn indien de requirements en scripts éénduidig zijn. Echter de overhead / communicatie kosten zijn niet te verwaarlozen.
  • Automatiseren van de testuitvoering
  • Requirements Based Testing, waarbij de functionele requirements de basis vormen.

Ik wil in deze blog verder ingaan op Requirements Based Testing en hoe dat in de praktijk zijn voordelen heeft.

Zoals de naam het al zegt, begint de aanpak bij de Requirements. Het omzetten van tekst naar een formele logica, in de vorm van een Cause Effect Graph (Oorzaak Gevolg Diagram) haalt de discussie over “hoe het nu eigenlijk bedoeld is” naar voren in het project. De kosten reductie daarvan is enorm.

Testcase design Cause Effect Graph, basis voor genereren van testcases

Testcase design Cause Effect Graph, basis voor genereren van testcases

Het bovenstaande plaatje geeft een indruk van een CEG (Cause Effect Graph).

Het rendement van omzetten van tekst naar formele logica is hoog.

  • Bij het uitwerken van tekst naar het model hebben we in de laatste 15 jaar geconstateerd dat 1 pagina tekst ca 30 vragen oproept tijdens de Requirements fase. Op dat moment zijn de reparatiekosten vaak nog te overzien, terwijl als de onduidelijkheden pas tijdens testen / oplevering naar voren komen, de kosten erg uit de hand lopen.
  • Als het formele model is opgesteld, kunnen nu reeds de testen en If-Then-Else logica worden gegenereerd. (zie ook presentatie van Dick Bender Bender-RBT-Product-Overview )

 

Geplaatst in Requirements Based Testing Getagd met ,

Exploratory Testing, wat wel, wat niet te testen

Exploratory Testing

Exploratory testing is een test methode die naast alom beschikbare richtlijnen en suggesties, vooral de kennis en inbreng van de software tester nodig maakt.
Naar onze mening valt of staat exploratory testing met de kennis en denkwijze van de software tester. Maar dat wil niet zeggen, dat er maar “in het wilde weg” getest moet worden.

Onze aanpak voor opleidingen en cursussen, alsmede gebruikte hulpmiddelen ziet er als volgt uit:

  • Opstellen van het Exploratory Testcharter op basis van Risk & Requirements analyse
    • Wat te testen, risico afdekkend, op basis van:
      • Gevolgschade bij niet goed functioneren
      • De technologie waarin de oplossing is gerealiseerd
      • Hoe en wat heeft het ontwikkelteam getest
    • Hoe veel tijd per test plannen we in, dit weer op basis van de gedefinieerde risico’s
    • Wat is de status van de te testen programmatuur en benodigde apparatuur
    • Hoe doen we (in overleg met de ontwikkelaars) de verslaglegging over de bevindingen
    • Wat is er nodig als voortgangsrapportage,
  • Exploratory Test uitvoering;
    • Een Walk Through, door de te testen functionaliteit, om de prioriteiten aan te scherpen. Deze stap kan ook als eerste gedaan worden voordat het testcharter wordt opgesteld. Deze stap is het beste te doen als een soort Demo door de ontwikkelaar. Eventuele tekortkomingen kunnen direct worden gecommuniceerd en vastgelegd.
    • Testen per charter.
      • Een charter zou kunnen zijn, “test het selecteren van een product, plaats het in de winkelwagen en reken af”
      • De exploratory tester zal dan zelf op ieder scherm / beslispunt testen gaan uitvoeren, die hem zinnig lijken op basis van zijn ervaring. Bij voorbeeld:
        • Bij product selectie heen en weer springen tussen producten, aantallen en winkelwagen. Onzinnige product aantallen kiezen, en producten met verschillende verzendwijzen combineren.
        • Winkelwagen manipuleren al dan niet met ingelogde account, cookies manipuleren etc.
        • Proberen verzendkosten te beïnvloeden, door te wisselen van land.
        • Tijdens afrekenen, BTW manipuleren, door niet bestaande BTW nummers te gebruiken, afreken proces stoppen als Payment Gateway getoond wordt etc.
      • De tester legt het gekozen pad vast in een script (voor hertest en overdracht), en maakt schermafdrukken van bevindingen.
    • In het bovenstaande geval simuleert exploratory testing het daadwerkelijke gebruik van veel gebruikers, met daarbij de aandacht op waar het mis zou kunnen gaan, b.v. door timing-issues. Zou zou het herhaaldelijk starten en stoppen van het afreken proces en de betaal gateway last kunnen krijgen van timing issues.

De finesses van Exploratory testing leggen wij graag uit:

  • in een workshop, bij u op locatie, en waarbij we de mindset van uw ontwikkelaars en testers scherp krijgen
  • of aan de hand van een project wat we bij u (op locatie of remote) uitvoeren, en tegelijkertijd uw team mee opleiden.
Geplaatst in Exploratory Testing

Software Test Management resultaat

Wij als specialisten op het gebied van Software Testen en Testmanagement, staan voor het bereiken van de gewenste resultaten door een  rigide software test planning en test management.
Een greep uit onze projecten:

Web site Testing

  • Performance testen van een Intranet applicatie
    • Op basis van architectuur analyse kon snel een testplan worden opgesteld voor deze specifieke software
    • Testmanagement concentreerde zich op de uitvoering van de performance testen op meerdere locaties, en vergelijkingen van het pakket op andere sites.
    • Uiteindelijk kon eenduidig worden vastgesteld, dat dit pakket geen oplossing biedt voor de gestelde eisen, ondanks de optimistische beloften van de leverancier.
  • Open Source Toepassingen Web based, onder andere Joomla, Drupal, Xoops
    • Architectuur onderzoek, als basis van testplan en het verdere testmanagement
    • Aansturing en optimalisatie leverde een pakketselectie, tot tevredenheid van de klant
  • Open Source test tools
    • Voor de inzet tijdens onze software test projecten, moeten wij regelmatig hulpmiddelen testen.. Daardoor kunnen wij kwaliteitsuitspraken doen over tools zoals Testlink, Mantis etc.
  • Opleiding van applicatiebeheerders in het gebruik van web test tools.
    • “Bij product” van website testen
    • Selectie van een mix van Open Source tools en systeem tools

Software Test Management

  • Aansturing van meerdere grote software test teams ( > 50 testers) bij o.a. Energie Leveranciers
    • Test Management op basis van “Risk Based Testing”, aan de hand van facturatie volumes
    • Onderbouwde adviezen voor “gefaseerd life gaan”, bij opeenvolgende deelconversies
  • Acceptatietesten van hypotheken toepassingen
    • Opleiding en inzet van Key-Users
    • Management het inzicht verschaffen, dat de zelfbouw applicatie niet aan de verwachtingen voldoet qua performance, en dat door de gekozen architectuur, aanpassingen een apart project zijn.

Test consultancy

  • Opzetten van meerdere testafdelingen
    • Interne medewerkers (Helpdesk, Applicatiebeheerders), kunnen nu zelf het merendeel van de testen uitvoeren
    • Bestaande en Open Source gereedschappen geïntegreerd
  • Test analyse training en coaching van Key-Users
    • Materie deskundigen kunnen nu zelf het merendeel van de functionele testen definiëren
    • Als “bijproduct” worden de procedures in kaart gebracht en vastgelegd

Opleidingen

  • Publieke meerdaagse cursussen
    • Optimum tussen algemene aanpak, en specifieke wensen
    • Deelnemers kunnen “de volgende dag beginnen”
  • In-house opleidingen, inclusief “train the trainer”
    • Implementatie van de testaanpak, train the trainer, en wij fungeerden als back-up voor de trainers bij ziekte.
  • Ontwikkelen van maatwerk opleidingsmaterialen, op basis van onze cursussen

Implementatie

  • Voortbouwend op de acceptatietesten, inrichten van complexe facturatie systemen
    • Opstellen van procedures, op basis van de testgevallen, zodanig dat zij in combinatie met de gemaakte testen, herbruikbaar zijn voor regressietesten
    • Inrichten van “opruim teams”, om de nazorg van de invoering van nieuwe software uit te voeren

Software selectie

  • Risico analyse, software test uitvoering en voorbereiden van de beslissing t.b.v. management
  • Opstellen van criteria voor software selectie
  • Klant begeleiding bij het inkoop proces

Deze lijst is in willekeurige volgorde, en niet uitputtend.
Om redenen van privacy kunnen wij hier niet meer informatie geven

 

Geplaatst in Testmanagement

Testmanagement

Test Management is één van onze kerntaken. Vanuit deze discipline hebben wij reeds veel klanten ondersteund. Daarom durven wij het volgende te schrijven over testmanagement.

Test Management deelt veel aspecten met Project Management, maar kent zeker evenzoveel verschillen:

  • De Test uitvoering is onderdeel van het projectplan, maar:
    • meestal vindt het testen pas aan het einde van het project plaats,
    • vaak kent het projectplan zoveel “flexibiliteit” , dat de uitloop tijdens de testfase weer moet worden ingelopen, met als gevolg extra risico’s die genomen moeten worden. Dit stelt hoge eisen aan het testmanagement, waarbij risico management het uitgangspunt is.
  • Testen en het daaraan verbonden testmanagement zijn meer Proces dan Project gericht. Het beschikbaar komen van de software in gedeeltes, het hertesten etc.  zijn administratief gezien processen, die de nodige administratie met zich mee brengen.
    • Wij vinden, dat slechts in een enkel geval kan worden volstaan met een “Excel Administratie” en dat de keuze van testmanagement tools een wezenlijk onderdeel is van het managen van software testen.
  • Gedurende deze fase ziet en “voelt” de organisatie het eindproduct vaak voor de eerste keer,
    • wat weer resulteert in wijzigingen
    • terwijl de key-users dan al vaak weer met andere taken zijn belast, zoals b.v. opleidingen
  • Alle gevonden issues hebben meerdere kanten;
    • Het “Hoera gevoel”, we hebben de fout gevonden
    • Pech voor de planning (zowel project management als testmanagement), want er is extra tijd nodig voor:
      • Vastlegging van het issue
      • Reparatie (door het bouwteam)
      • Hertesten van het issue, inclusief administratieve tijd, die nog verergert indien het issue weer faalt.

Bij het opzetten van een testproject ligt bij ons testmanagement de nadruk op: Eenvoud, herhaalbaarheid en GBV (Gezond Boeren Verstand).

Maar…ieder testproject gaat onderuit als er niet een sluitende testadministratie is opgezet. Wij helepen u daar graag bij met producten uit onze shop, of via direct contact.

Geplaatst in Tmap, Testmanagement, ISTQB, ISO9126-ISO25010

Website Testen

Bij het opstellen van een testplan voor een website, is het handig om de volgende informatie bij de hand te hebben:

  • Verwacht aantal gebruikers voor de website
  • Type gebruikers en de verwachte typen hardware
  • Response tijden
  • Technologie, zoals server, database
  • Gewenste beveiliging zoals HTTPS, 2 factor authentication etc.
  • Op browser technologie gebaseerd, of web interfacing zoals b.v. SOAP

Binnen het testplan voor de website / webshop wordt o.a. de volgende informatie opgeslagen:

  • Performance criteria en server belasting
  • Logische testgevallen
  • Security testgevallen
  • Back-up scenario’s en hun testen.

Wij helpen u graag verder, met een template uit de shop, of met 1 op 1 ondersteuning.

Geplaatst in Tmap, Testplan, ISO9126-ISO25010, Website, Webshop