Vaak krijgen wij als testers van onze projectmanager de vraag: hoe lang duurt het om de applicatie te testen? We kunnen dan antwoorden dat we een week nodig hebben om alle gemaakte testscripts een keer uit te voeren. Maar dat is niet het antwoord dat we geven. Waarom? Omdat een projectmanager niet wil horen wanneer de test klaar is, hij wil horen wanneer de software klaar is.
Stel, na twee testrondes, geheel volgens plan, is de conclusie dat de software niet voldoet. Wij hebben dan misschien optimaal gepresteerd, een projectmanager wordt niet enthousiast van het nieuws dat de software nog zo brak is als het IJsselmeer. Hun opdracht is dan nog niet af, en daarmee de onze ook niet. Projectmanagers zijn dus geïnteresseerd in het moment waarop de software klaar is voor productie, en het vervelende is: dat vragen ze aan ons!
Het lijkt alsof de algemene perceptie is dat testers binnen de afgesproken testplanning kwaliteit moeten bereiken, in plaats van aantonen. Iedere tester heeft weleens meegemaakt dat een stakeholder zich openlijk afvraagt waarom dat testen zo lang duurt. En iedere tester heeft weleens ervaren dat de doorlooptijd van de testplanning ter discussie gesteld wordt.
Tuurlijk, het tijdig bereiken van kwaliteit is mede afhankelijk van het zo vroeg mogelijk vinden van de belangrijkste fouten, het helder beschrijven en reproduceerbaar maken van bevindingen, en het onderhouden van goede relaties met ontwerpers en ontwikkelaars. Maar uiteindelijk moeten fouten snel en efficiënt worden opgelost door de ontwikkelaars! Testers kunnen dit onmogelijk garanderen. Vaak is dus het bereike en, niet het aantonen van kwaliteit oorzaak van uitloop in het testtraject.
Een paar veel voorkomende voorbeelden:
– In de eerste testronde worden meer en zwaardere bevindingen gevonden dan ontwikkelaars in de eerstvolgende oplevering kunnen oplossen. Pas in latere testrondes worden meer bevindingen opgelost dan er gevonden worden en loopt het aantal openstaande bevindingen terug;
– Niet alle geplande functionaliteit kan in de eerste testronde onderzocht worden. Een bevinding kan achterliggende functionaliteit blokkeren, die daardoor pas in een volgende release getest kan worden. Als die bevinding eenmaal is opgelost blijken ook in de achterliggende functionaliteit nog bevindingen te bestaan;
– Gemiddeld 20 provent van alle bevindingen (eigen ervaring) wordt niet correct opgelost. Dat betekent dat als in de tweede oplevering honderd bevindingen zijn opgelost, er gemiddeld twintig bevindingen heropend worden. Dat staat nog los van eventuele nieuwe bevindingen die gedaan worden.
Het bereiken van kwaliteit is dus een delicaat samenspel van ontwerper, ontwikkelaar en tester. En de testplanning is dat idealiter ook. Moeten testers dan stoppen met het afgeven van testplanningen? Nee, zeker niet! Testers verzamelen beroepshalve namelijk zowel expliciet en impliciet veel informatie over processen. Dat betekent dat testers beter (of minder slecht) dan anderen in staat zijn om een redelijke inschatting te geven hoe lang het duurt alvorens een bepaald kwaliteitsniveau bereikt is.
Wel kunnen we als testers beter communiceren over de waarde van een testplanning:
– vertel de projectmanager dat de doorlooptijd van het testtraject enerzijds wordt bepaald door de mate waarin testers bevindingen kunnen aantonen, en anderzijds door de snelheid waarmee ontwerpers en ontwikkelaars bevindingen kunnen oplossen;
– communiceer tijdig wanneer de planning dreigt uit te lopen en maak inzichtelijk wat de oorzaken zijn;
– als een projectmanager het testtraject inkort, wijs erop dat het risico toeneemt dat de kwaliteit aan het einde van het geplande traject tegenvalt;
– vraag de projectmanager te organiseren dat ook ontwikkelaars hun oploscapaciteit moeten verhogen om de nieuwe deadline te halen, iets wat bij het inkorten van testplanningen vaak wordt vergeten.
Ik neem in het planningshoofdstuk van mijn testplannen standaard de volgende zin op:
“Deze planning geeft aan hoe lang het duurt om de software conform de in dit document beschreven scope en werkwijze te testen, waarbij de kwaliteit van de software wordt vergeleken met de afgesproken acceptatiecriteria. Het bereiken van kwaliteit is een projectproduct, geen testproduct: testen draagt daar enkel aan bij door kwaliteit te onderzoeken en erover te rapporteren. Hoewel x testrondes zijn ingepland, kunnen minder, of meer rondes nodig zijn om het gewenste kwaliteitsniveau te bereiken.”
Ik heb nog geen projectmanager meegemaakt die na het lezen van deze zin niet de behoefte voelt om erover te discussiëren. En dat is perfect! Tenslotte is bewustwording de eerste stap van verbetering.
20 jaar geleden rolde ik het projectmanagementvak in via het test- en acceptatietraject. Dat wens ik iedereen toe.
De toestanden die ik daar heb meegemaakt hebben mij gevormd. Tot vandaag de dag benader ik mijn projecten dan ook vanuit een acceptatie-optiek. En dat begint dus al aan het begin!
Dat het PM-curriculum *minimaal* TMap-Foundation of vergelijkbaar dient te bevatten staat voor mij als een paal boven water.
Echter, alle jaren tot op vandaag de dag heb ik daarop glazige blikken gekregen of ronduit afwijzing. Zowel bij projectmanagers, lijnmanagers als bij opleiders. En ook bij organisaties die zichzelf als zéér professioneel zien en als zodanig ‘verkopen’.
De cyclus risico’s – requirements – testen – acceptatie is keihard.
Doe er wat mee, ‘or suffer the consequences’.
–