Je testscripts zijn zo goed als je requirements
Wat maakt een goed testscript?
Die discussie had ik recent met een collega. Er blijken een hoop verschillende manieren te zijn om scripts te maken en onderhouden. Om tot de beste applicatie te komen, is testen cruciaal. Maar wat zijn nu eigenlijk goede testscripts? Als je dit aan tien collega’s vraagt krijg je waarschijnlijk ook tien verschillende antwoorden. Toch waren wij van mening dat er wel altijd eenzelfde vertrekpunt zou moeten zijn; de requirements.
Door: Nico Welmer, Senior Testautomation Engineer bij Heeyoo
Vertrekpunt van testscripts zijn requirements
Natuurlijk moet een effectief testscript voldoen aan alle eisen en richtlijnen zoals beschreven in de TMap of ISQTB methodiek. Hierin kun je informatie vinden over het juiste formaat, effectief beheer van de testscripts, identificatie, condities en het verwachte resultaat. Dat er eisen zijn is belangrijk, maar het vertrekpunt voor je testscript zijn de requirements. Als deze slecht gedefinieerd zijn, dan kunnen je scripts wel voldoen aan alle eisen, maar toch compleet nutteloos zijn. Behalve als deze aantonen dat je requirements niet goed zijn :-).
Je ziet vaak dat requirements al geschreven en compleet ontwikkeld zijn door het developmentteam zonder het testteam te raadplegen. In een ideale situatie zouden Testers al veel eerder betrokken worden. Zo voorkom je dat er later problemen ontstaan. In de praktijk komen we echter regelmatig vage of onvolledige requirements tegen die, als het even tegenzit, ook nog heel anders uitgelegd worden door een ontwikkelaar. Als Testers vooraf de requirementsdocumenten kunnen reviewen, kunnen zij ook veel meer waarde toevoegen.
Beschrijf ook de non-functional requirements
Zo komt het voor dat de functionele requirements goed zijn gespecificeerd, maar dat over de non-functional requirements nog niet goed is nagedacht en dat deze bestaan uit algemeenheden en/of niet meetbaar of realistisch zijn. Denk bijvoorbeeld aan de performance van een applicatie of nieuwe website. Hier is pas aandacht voor als er problemen zijn op dit gebied. Dan ben je al te laat en moet er relatief veel tijd en moeite worden gestoken in het oplossen hiervan.
Maar ook als er wel is gekeken naar de performance-eisen, kun je na livegang alsnog ontdekken dat de gebruikersaantallen en de werkelijke belasting niet aansluiten bij de verwachte gebruikersaantallen en verwachte belasting. Daarom is het verstandig hier samen met het testteam van tevoren serieuze aandacht aan te besteden en te zorgen dat de non-functional requirements beter aansluiten bij de praktijk.
Een succesvolle applicatie opleveren is een team effort. Met het vroegtijdig betrekken van Testers bespaar je bovendien uiteindelijk ook op ontwikkelkosten en ergernis bij gebruikers door minder bugs en onverwachte verstoringen in je applicatie.
