Recentelijk had ik een discussie met een collega over wat goede testscripts zijn. Er was een brede discussie ontstaan, nadat bleek dat er binnen de organisatie diverse manieren waren ontstaan voor het maken en actueel houden van testscripts. Toen alle stofwolken waren neergedaald en rustig met een helikopterview werd gekeken naar de testscripts rees de vraag: wat zijn nu precies goede testscripts en waaraan moeten ze voldoen? Uiteraard alle eisen en richtlijnen, zoals die te vinden zijn in de TMap of ISQTB methodiek, zoals het formaat, het beheer van de testscripts, de identificatie, de condities en het verwachte resultaat, zijn van belang.
Maar al gauw kwamen we tot de conclusie dat de requirements toch het startpunt zijn van je testscript. Als de requirements slecht gespecificeerd zijn, dan kunnen je testscripts voldoen aan alle eisen, maar toch compleet nutteloos zijn, behalve dan dat die defacto aantonen dat je requirements niet goed zijn.
Mijns inziens zouden business-analisten en stakeholders eerder in het project de requirements moeten bespreken met de testers om zo vroegtijdig onduidelijkheden eruit te halen. Vaak kom je vage of onvolledige requirements tegen die, als het even tegenzit, ook nog heel anders uitgelegd wordt door een ontwikkelaar. Met de nieuwe functionaliteiten en bij behorende requirementsdocumenten heeft het testteam wel de mogelijkheid gekregen om deze vooraf te reviewen, wat als gevolg had dat er vaak meerdere wijzigingen plaatsvonden in de requirementsdocumentatie.
Soms zie je dat de functionele requirements goed zijn gespecificeerd, maar dat het vragen naar non-functional requirements vaak eerst een glazige blik oplevert, gevolgd door wat algemeenheden, die verre van meetbaar of realistisch zijn.
Daarom is het belangrijk voor bijvoorbeeld de performancetesten om vooraf duidelijkheid te krijgen over de non-functional requirements aangaande de performance van een nieuwe applicatie of website. Veelal zie je dat de put pas gedempt wordt als het kalf is verdronken. Dus pas als er problemen zijn wordt veel tijd en moeite gestoken in het oplossen van het probleem en dan pas wordt er serieus nagedacht over de performance-eisen.
Ook blijkt vaak als er wel goed nagedacht is over de performance-eisen dat na live-gang de gebruikersaantallen en de werkelijke belasting, de verwachte gebruikersaantallen en verwachte belasting niet benaderen. Daarom is het verstandig om hier lering uit te trekken voor eventuele vervolgtrajecten, zodat in de toekomst de non-functional requirements beter aansluiten op de praktijk.
Helaas is deze organisatie geen uitzondering, binnen een groot gedeelte van de verschillende projecten waaraan ik heb gewerkt zijn testers pas laat betrokken bij het project en zijn de requirements al geschreven en veelal ook compleet ontwikkeld door het developmentteam.
Daarnaast is er vaak te weinig aandacht geweest voor de non-functional requirements in de requirementsdocumentatie. Daarom ligt hier een grote besparing voor het oppakken, schakel eerder je testteam aan bij je project en bespaar uiteindelijk op ontwikkelkosten en ergernis door minder bugs en minder verstoringen.