Enige tijd geleden was één van mijn werkzaamheden voor een toenmalige klant het begeleiden van een acceptatietest voor de eerste iteratie van een nieuw systeem. Op basis van de klanteisen was gekozen om ontwerp en realisatie uit te besteden aan een externe ontwikkelstraat. De leverancier heeft deze straat vanzelfsprekend omschreven met een behoorlijke hoeveelheid turbo-kreten om aan te geven hoe productief de straat wel niet is. De verwachtingen waren dan ook hoog gespannen en in een proof-of-concept fase niet teleurgesteld.
Gezien de turbo-ontwikkelstraat en het beperkte budget kreeg ik te horen dat de inzet van een professionele tester niet nodig is (de leverancier zet al professionele testers in), de gebruikers zullen het testen zelf voor hun rekening nemen. Enkel een gebruikersacceptatietest wordt voorzien, een functionele acceptatietest is niet nodig, wel moet ik de tests van de leverancier beoordelen. Hmm, kan werken…
Ik beleg een kickoff-sessie met de gebruikers, we bespreken de test, wat we als deelobjecten en te testen kenmerken zien, inclusief risico-indicatie en komen zo vrij vlot tot een productrisicoanalyse en globale teststrategie, inclusief een taakverdeling. Dat gaat voorspoedig. Snel de resultaten vastleggen in een testplan! Het eerste kinkje is als de hoofdgebruiker me belt met de opmerking “ja, maar je denkt toch niet dat we zoveel tijd gaan besteden”. Met enig onderhandelen komen we eruit, een paar onderdelen dan toch maar (nog) lichter testen.
Kort daarna wordt het plan geaccepteerd door iedereen, inclusief de leverancier. Een tweede kinkje als ik vervolgens mijn mooie maar toch al kleine testuitvoeringsweek + hertestweek niet terugzie in de opleverplanning van de leverancier. “Oh, even vergeten, passen we aan”. Gelukkig maar weer.
Een goede afspraak (op initiatief van de testmanager van leverancier) is dat we een week voor start acceptatietest al een keer komen testen in de systeemtestomgeving. Ook voor mijn testers/gebruikers een goede gelegenheid om te wennen aan wat er straks op ze af komt. Enthousiast plan ik anderhalve dag in. Later belt de collega-testmanager me voorzichtig op dat anderhalve dag wel wat veel lijkt. Er zijn tenslotte dan pas 4 functies door de systeemtest gekomen. Hmm, lijkt nog niet veel.
Gelukkig zijn de bijbehorende testscripts goed uitgewerkt, dat geeft vertrouwen.
Uur U, start acceptatietestuitvoering, nadert. Voor het belangrijkste/meest risicovolle onderdeel van het systeem heeft een materiedeskundige een degelijke testset opgezet en deze (zonder resultaat-voorspelling, deze houden we voor onszelf) al gestuurd naar de leverancier. Voor de overige functionaliteit de gebruikers geholpen door ze te voorzien van checklists van te testen zaken, met een flinke dosis error guessing van hun kant erbij.
Enigszins verontrustend is dat slechts enkele delen functioneel ontwerp zijn opgeleverd, de testscripts van leverancier zijn ook nog volop in bewerking. Navraag leert dat hier wat achterstand is. Hmm.
Uur U: hoewel de achterstand niet lijkt ingelopen, doet de combinatie van flinke tijdsdruk en een goede dosis nieuwsgierigheid ons toch besluiten te starten. Pas bij aankomst ontvangen we de releasenotes: er zijn 40 openstaande bevindingen, ontwerpen lopen nog achter en grote stukken functionaliteit zijn nog niet opgeleverd. Dit voldoet niet aan de afgesproken start-criteria voor de acceptatietest, maar ja, we zijn er nou toch en willen graag aan de slag.
De gebruikers installeren zich achter een PC, en vragen me heel terecht of de testers elkaar niet in de weg kunnen zitten met hun testdata. Gelukkig is dat geen probleem, stel ik ze gerust. Alles begint met zogenaamde XYZ-objecten, dus als iedere tester zijn eigen object aanmaakt, kan er niets gebeuren. Ik maak snel zo’n object aan voor de vragensteller en knik hem bemoedigend toe. Achter me hoor ik op dat ogenblik een verbaasde uitroep “waar is mijn object opeens gebleven???” …
Vermaak ik me? Ja, opperbest!
—————————————————
Tim Koomen, co-auteur van TMapNext en TPI, zelfstandig testconsultant
