Testen is meer dan "de race om zoveel mogelijk bugs"

Het is in: zoveel mogelijk bugs vinden in zo weinig mogelijk tijd. Er zijn een heleboel deskundigen, boeken en cursussen over, waarbij het doel soms sterk lijkt op: hoe vindt je zo snel mogelijk zo veel mogelijk fouten voor één invoerveld? Wat mij opvalt: deze testkennis wordt voornamelijk naar voren gebracht door mensen die werken in grote testteams met meerdere testers. En met een vrij groot testbudget in uren. 

Voor er misverstanden ontstaan: elke tester moet in staat zijn om dit soort testen uit te voeren. Het goed testen van invoer en validatie is een basisvaardigheid waarover een tester moet beschikken. Het probleem ontstaat als testers deze kennis gaan toepassen zonder een goede teststrategie. Als ze op het eerste scherm dat ze vinden doorgaan met testen, net zo lang totdat alle mogelijke te bedenken varianten geweest zijn. Waardoor grote fouten in scherm nummer vier pas ontdekt worden vlak voor het eind van de sprint of de deadline. Of als testers volledig losgaan op het testen van invoerschermen, maar de belangrijke processen en berekeningen in het testen naar achteren schuiven. Omdat ze deze eigenlijk moeilijk vinden om te testen of er tegenop zien.

In een groot testteam heb je vaak een zeer ervaren tester of testcoördinator, die ervoor zorgt dat de belangrijke onderdelen en moeilijke onderdelen op tijd getest worden. Je kan rustig voluit gaan testen op jouw scherm, want de rest van de applicatie goed testen, dat ligt in handen van anderen. Dit wordt anders als je alleen of met heel weinig testers in een team bent. En je daardoor niet alleen zelf moet testen, maar ook je eigen strategie moet gaan bepalen. Kan je dat wel?

Basis testvaardigheden

Als tester moet je er eerst voor zorgen dat je over genoeg testvaardigheden beschikt, om alle mogelijke verschillende onderdelen in een applicatie te testen. Je moet overtuigd genoeg zijn van je vaardigheden als tester, om in ieder geval de verleiding van afstel/uitstel te vermijden. Ik ben zelf van mening dat je minimaal de volgende vier applicatieonderdelen moet kunnen testen:

1. Een invoerscherm met bijbehorende invoer- en validatietesten
2. Een proces in de applicatie, waarin tenminste drie schermen betrokken zijn
   B.v. een proces met drie schermen: invoeren van uren, goedkeuren van uren, uitbetalen van uren
3. Een berekening met minimaal vier verschillende inputwaardes
   B.v. een factuur voor een webwinkel, waarbij het totaalbedrag van de bestelling, eventuele kortingsbonnen, klantenkorting en betaalkosten voor de creditcard tot een correct eindbedrag moeten leiden
4. Een beslisproces, waarbij de uitkomst bepaald wordt door minimaal drie verschillende factoren
   B.v. toegangsrechten in een applicatie testen, waarbij datgene wat de gebruiker mag in de applicatie bepaald wordt door zijn functie, zijn afdeling en zijn bedrijf.

Prioriteren van testen

Wanneer je voldoende testvaardigheden hebt, moet je nog weten in welke volgorde je moet gaan testen.

De basis van prioriteren is weten welk onderdeel of proces het eerst getest moet worden. In veel gevallen is deze prioritering al bekend, namelijk de volgorde van de story's. Daarom wil ik hier niet veel aandacht aan besteden. Mocht deze niet bekend zijn, dan kan je altijd hulp vragen aan een teamleider of projectleider om de juiste prioriteit vast te stellen.

Maar een prioritering bij het testen van een onderdeel of proces is ook verstandig. Wanneer je een onderdeel van de applicatie of een proces in de applicatie test, dan is het verstandig ernaar te streven om eerst de grootste fouten eruit te halen en daarna de minder grote fouten. Grote fouten kosten vaak meer tijd om op te lossen. Daarnaast kunnen ze ook bepaalde testen blokkeren. Als de "Opslaan" knop geen gegevens opslaat, kan je ook niet nagaan of gegevens goed opgeslagen worden. Hoe eerder je ze dus vindt, hoe beter!

Wat een grote fout is en wat niet kan per bedrijf en per applicatie verschillen. Het voorstel dat ik hieronder doe, zal in veel gevallen werken, maar het kan nodig zijn deze voor jouw situatie aan te passen. Ik hoop vooral dat het proces van prioritering duidelijk wordt.

Test 1: Blockers
Test de applicatie door met de Franse slag. Let nu nog niet op correctheid, let er alleen op of er foutmeldingen of fouten zijn die het gebruik van de applicatie volledig onmogelijk maken. En daarmee het testen blokkeren. Denk hierbij aan een "Volgende" knop die niet naar het volgende scherm gaat of een "Opslaan" knop die geen gegevens opslaat.

Test 2: Majors
Deze test gaat voornamelijk om de correctheid. Worden de gegevens goed opgeslagen? Worden de juiste gegevens getoond? Worden berekeningen goed uitgevoerd? Worden de juiste knoppen, menu's en invoervelden op de juiste momenten getoond? Anders gezegd: als een gebruiker geen fouten maakt, werkt de applicatie dan goed?

Test 3: Minors
De nadruk ligt hier veel op foutafhandeling. Wat gebeurt er als een gebruiker foute gegevens invoert? Wat gebeurt er als een gebruiker in een wizard besluit terug te gaan naar een vorige stap? Werkt de annuleren knop? Anders gezegd: werkt de applicatie ook goed, als de gebruiker fouten maakt?

De testbasis

Waar het om gaat, is dat je als tester niet alleen probeert om veel bugs te vinden. Probeer ook om alle onderdelen goed te testen, juist als ze moeilijk zijn. Al zal hierdoor het aantal bugs per uur afnemen, de test is zeker niet minder belangrijk. En streef ernaar om de grootste bugs het eerst te vinden, om het ontwikkelproces en het testproces zo soepel en snel mogelijk te laten verlopen. Als je beide kan, dan kan je desnoods als enige tester in het hele bedrijf toch goed testwerk afleveren.