Documenteren tijdens het testen - Gewoon doen!

Iedere tester kent de situatie: het testen wil niet lukken. Je weet als tester niet hoe het moet werken. En/of de programmeur weet niet hoe het moet werken. En/of jullie weten het allebei, maar er zijn zoveel situaties... "Oh ja, daar hadden we ook rekening mee moeten houden!" Ondertussen komt tijdens het testen de ene naar de andere fout naar boven. Of nog erger: je moet het testen opgeven of stoppen. Je kennis is op of de tijd is op en goed testen kan of mag niet meer.

Documenteren hoe iets moet werken, zeg maar functionele documentatie, was en is altijd een probleem. Er is bijna niemand die het leuk vindt. Als je geluk hebt, is er nog iemand die het bij de eerste bouw beschrijft. Maar daarna deze documentatie bij elke wijziging weer opnieuw aanpassen, is vaak teveel gevraagd. Soms is er ook nog het omgekeerde probleem: er is zoveel documentatie, dat niemand meer weet wat waar staat. Processen staan beschreven in wel 5 documenten en de documenten spreken elkaar tegen. Als men processen in de vele documentatie nog weet te vinden.

Nu wordt functionele documentatie zeker niet als taak van een tester gezien. Als er al documentatie moet worden geschreven, gebeurt dat voor het testen. En deze documentatie wordt dan tijdens het testen gebruikt. Dus de documentatiefase is bij de functionele test in principe afgerond. Maar juist tijdens het testen blijkt te vaak dat de documentatie mist of niet klopt. Zoals hierboven beschreven, blijkt dit vaak doordat er steeds opnieuw fouten naar boven komen. De belangrijkste oorzaken:

• Het ontwikkelteam is niet voldoende op de hoogte van de domeinkennis om bepaalde processen en gegevens te kunnen controleren
• De programmeurs zijn niet voldoende op de hoogte van processen en business rules in de applicatie om hiermee rekening te kunnen houden tijdens het bouwen of aanpassen van de applicatie
• Er worden regels, verwachtingen of specificaties vergeten. Nieuwe worden niet gebouwd. Bestaande worden niet meegenomen of gecontroleerd bij aanpassingen.

Waarom zou je als tester dan functionele documentatie willen schrijven? Omdat je als tester een kwalitatief goed product wil. Omdat je als tester het fix-traject wil verkorten. Omdat je als tester bij een volgende keer fouten wil voorkomen.

Nu moet je niet denken dat je plotseling de hele applicatie moet gaan documenteren, als dat nog nooit gedaan is. Het is voldoende om datgene vast te leggen wat er getest moet worden. Leg die informatie vast, die je wil testen en waarvoor documentatie nodig blijkt te zijn. Let er wel op dat je niet alleen de wijzigingen vastlegt. Leg ook de informatie vast die je blijkt te missen voor het goed uitvoeren van een regressietest.

Dit mag onzinnig lijken, want wat helpt dat kleine beetje documenteren nu? Mij is echter in de praktijk anders gebleken. Belangrijke functies worden in een bedrijf vaak aangepast of uitgebreid, waardoor ze meestal meer door een testfase heengaan dan minder belangrijke functies. De eisen en wensen voor die functies zijn namelijk zo belangrijk, dat een aanpassing sneller interessant is voor de organisatie. Hierdoor heb je automatisch het merendeel van de risicogebieden bij de belangrijke functies vaak al binnen een jaar vastgelegd. En zal je deze documentatie al vrij snel weer kunnen gebruiken, waardoor het nut zich snel bewijst.

Het allerbelangrijkste bij vastleggen van functionele documentatie: zorg ervoor dat je de documentatie zo vastlegt dat je de documentatie ook weet terug te vinden. Bij voorkeur zelfs zo dat iedereen in je ontwikkelteam de documentatie weet terug te vinden. En nog beter: dat ieder toekomstig lid van je ontwikkelteam, ook een nieuwe tester, de documentatie weet terug te vinden. De regels hiervoor:

• Kies voor een goede basis indeling. Dit kan zijn per proces, per module, per scherm, per menu-item. Maar kies een indeling die logisch is voor jouw applicatie 
• Leg informatie over een scherm of een proces maar op 1 plek vast
• Als de informatie in het ene document voor een ander document van belang kan zijn, verwijs dan in het ene document naar het andere document

Stel de documentatie bij voorkeur met hulp van de ontwikkelaar en met de eindgebruiker (of een ander persoon met domeinkennis) op. En start hiermee zeker zodra iets drie keer achter elkaar is gefaald, doordat men zaken niet wist of vergat. Houd je niet strikt aan je rol, maar ga voor de kwaliteit. Durf te documenteren!

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.