Informatietechnologie
nog eens goed uitgelegd
softwareontwikkeling | analyse | laatst bijgewerkt op 2022-11-04

acceptatietestplan

Een vooraf opgesteld plan voor het naderhand uitvoeren van een acceptatietest.

Een acceptatietest is meestal de laatste test die uitgevoerd wordt voordat het product opgeleverd wordt aan de opdrachtgever. Om te zorgen dat deze acceptatietest goed uitgevoerd kan worden, dient er vooraf een plan gemaakt te worden. Het idee van de acceptatietest is vaststellen of de opdrachtgever het product in de huidige vorm zal accepteren om in productie te nemen. Het is daarom logisch om dit plan tijdens de analyse te maken, omdat dan ook vastgelegd wordt wat de wensen van de opdrachtgever zijn. Het is relatief eenvoudig om bij het vastleggen van een gewenste functionaliteit ook direct aan te geven hoe deze functionaliteit getest dient te worden. Eventueel kan de opdrachtgever geraadpleegd worden om mee te denken over de op te stellen testscenario's om ervoor te zorgen dat deze zo goed mogelijk lijken op het werkelijke gebruik van het informatiesysteem.

Plan

Het plan omschrijft de uit te voeren tests en is zo geschreven dat iemand anders het zou kunnen uitvoeren. Er zijn vele sjablonen en manieren voor het maken van een acceptatietestplan, maar allen dienen ongeveer hetzelfde nut, namelijk bevestigen dat het product voldoet aan de vooraf vastgestelde wensen van de opdrachtgever. Een veel voorkomende aanpak is om dit te doen per use-case (of user story). Dus voor elke use-case bestaat er een set van tests die de correcte werking van deze use-case afdekken. Dit is ook de reden dat het acceptatietestplan gemaakt wordt in de analyse, omdat dan ook de use-cases bepaald worden.

De sjabloon die ik hier gebruik is een sterk vereenvoudigde vorm van een adviessjabloon van ISTQB, zodoende is het gebaseerd op een theoretisch kader, maar is niet dusdanig omvangrijk dat het een studie op zich is.

Een test heeft een code die de bijbehorende use-case aanduidt en een volgnummer, omdat er per use-case meerdere tests zijn. Het eerste te gebruiken volgnummer is 0, dit is de “happy flow”-test, in andere woorden: de test die het reguliere gebruik van de use-case simuleert en dan bepaalt of de normale werking correct is. Wanneer de 0-test faalt is het niet zo zinvol meer om de overige tests bij deze use-case te doorlopen, want het systeem zal nooit aan de wens van de opdrachtgever kunnen gaan voldoen. Wanneer de 0-test slaagt worden de overige tests uitgevoerd beginnend bij 1. Vanaf nummer 1 zijn de test van het karakter “monkey tests”, dat wil zeggen: het zijn tests die bewust een verkeerd gebruikersgedrag simuleren en bepalen of het systeem daar correct mee omgaat. Vaak is het zo dat een systeem een foutmelding dient weer te geven of een correctie dient uit te voeren.

Voorbeeld

Hieronder een voorbeeld voor een hypothetische use-case "Gebruiker aanmaken". Tijdens het maken van het plan kun je uiteraard de laatste 2 kolommen nog niet invullen. Per use-case maak je een soortgelijke tabel, die telkens weer bij 0 begint, omdat elke use-case uiteraard een "happy-flow"-test heeft. De testinstructie dient geschreven te zijn vanuit het perspectief van de eindgebruiker en dient het gedrag van deze eindgebruiker te simuleren. Het dient dus voor de tester mogelijk te zijn om de instructie uit te voeren zonder enige kennis te hebben van de interne werking van het informatiesysteem, we noemen dit ook wel ooit black box testen.

GEBRUIKER AANMAKEN

CODE INSTRUCTIE VERWACHT RESULTAAT WERKELIJK RESULTAAT GESLAAGD?
GA_0 Vul als voornaam “Bas” in, en als achternaam “Michielsen”. Bevestig de invoer. De gebruiker wordt aangemaakt en het systeem meldt dit op het scherm.
GA_1 Vul als voornaam “Bas” in, maar laat het veld voor achternaam leeg. Bevestig de invoer. De gebruiker is niet aangemaakt, het systeem meldt dat achternaam verplicht is.
GA_2 Vul niets in. Bevestig de invoer. Het systeem onderneemt geen actie.

Uitvoeren van de tests

Het uitvoeren van de tests gebeurt uiteraard niet tijdens de analyse, want dan is het informatiesysteem nog niet beschikbaar. Het is goed om de tests te definiëren in de analyse, omdat deze het directe gevolg zijn de use-cases van het informatiesysteem. Het uitvoeren van de tests kan uiteraard pas bij het opleveren. Kijk hiervoor in het artikel acceptatietest.

Conclusie

Een acceptatietestplan geeft aan op welke manier een te ontwikkelen informatiesysteem straks getest dient te worden. Het plan gaat altijd uit van het perspectief van de eindgebruiker en de tester simuleert dus het gebruik van de het systeem alsof hij of zij de opdrachtgever is. De tester dient het informatiesysteem te kunnen behandelen als een black box, omdat hij of zij geen kennis heeft van de interne werking van het informatiesysteem.