Een Agile testscript

Het schrijven van een testscript komt vaak overeen met het schrijven van allesomvattende testdocumentatie. Of het bijdraagt aan werkende software is vaak de vraag. Agile en testscript lijken dan in tegenspraak met elkaar. Maar het testscript is toch niet voor niets uitgevonden? Kan het binnen Agile testen dan niet een waardevol middel zijn?

In een Agile omgeving is het van belang dat het werk van teamleden overgenomen kan worden door andere teamleden. Van de ene tester in het team naar de andere tester in het team. En soms zelfs van een tester naar een ontwikkelaar. Daarnaast kom je ook als tester in een Agile omgeving de volgende situatie nog steeds tegen: ingewikkelde processen testen kost veel tijd, als je bij de start van het testen er geen kennis over hebt. Als je het kennis vergaren eerder kan doen, kan je de testuitvoering flink in tijd verkorten. Oplossing voor beide situaties: het testscript. Wanneer iedereen in het team een testscript kan begrijpen, kan het ook door iedereen uitgevoerd worden. En als complexe processen alvast voorbereid zijn met een testscript, dan kan je, na het afbouwen, sneller de testen uitvoeren. Zodat je team sneller weet hoe de kwaliteit is en dichter op de bouw eventuele fouten op kan pakken.

Dat betekend niet dat het verstandig is om meteen hele grote, uitgebreide, gedetailleerde testscripts te schrijven. In je team kan je uitgaan van een zekere basiskennis van de applicatie. Al je teamleden zouden in staat moeten zijn om in b.v. een loonadministratie een nieuwe medewerker in te voeren en een loonbatch te starten. Waar het om gaat, is dat je als tester die informatie vastlegd, die ze niet weten: jouw testkennis. En wat is die kennis? Die kennis zijn de testcases, die door jou, op basis van je ervaring en je kennis als tester zijn opgesteld. Die testcases leg je vast in een testscript. Zodat iedereen in het team, ook zonder jouw kennis en ervaring, goed kan testen.

Welke gegevens leg je vast en welke gegevens niet? De gegevens die je minimaal vastlegd, zijn de gegevens die leiden tot het gewenste te controleren resultaat. Als je dus wilt controleren of een medewerker recht heeft op een bepaalde 50+ regeling, dan is het niet nodig in het testscript vast te leggen wat de naam, het adres en de functie van een medewerker is. Wat je wel vast moet leggen, is welke geboortedatum je invoert. Zo kan je bijvoorbeeld ervoor zorgen dat iedereen de juiste randgevallen test. In dit geval 49, 50 en 51 jaar.

Daarnaast leg je datgene vast wat je wil controleren. Stel dat bij iemand van 50+ op het scherm een speciale 50+ merkteken getoond wordt. Leg dan alleen vast dat hierop gecontroleerd moet worden. Het controleren van alle andere gegevens is niet nodig, dat ben je op dit moment niet aan het testen.

Houdt de beschreven invoer en de beschreven controles op deze wijze zo kort mogelijk, zodat de documentatie compact blijft. Je kan zelf bepalen of je de beschrijving van de invoer op logisch (<50, 50, >50) of fysiek niveau (49 jaar, 50 jaar, 51 jaar) vastlegt. Dit kan van de te testen procedure, de uit te voeren test en/of van het team afhangen. Als je twijfelt, kies dan voor de meest voorschrijvende methode, het fysieke niveau. Dit is vaak nauwelijks meer werk en wordt in ieder geval altijd goed overgenomen.

Een testscript schrijven voor Agile kan dus handig zijn. Vooral als overdragen mogelijk moet zijn of om testtijd te besparen in het latere deel van het traject. Maar houd je document zo compact mogelijk, door alleen die gegevens vast te leggen die je teamleden minimaal nodig hebben om de test uit te voeren. Ga ervan uit dat je teamleden de te testen applicaties goed zullen kennen. Dan zal je testcript leiden naar goed werkende software en niet naar alles omvattende documentatie.