De mythe van tijdsbesparing op testuitvoering

Afgelopen zomer vond er een grote planningsworkshop plaats op het project waar ik testmanager ben. Deze workshop zou precies in de eerste week van mijn zomervakantie plaatsvinden. Nu heb ik hart voor de zaak, maar hecht ik ook veel waarde aan mijn zomervakantie. Dus heb ik voor mijn zomervakantie aanbevelingen achtergelaten, waarop ik het nu volgende artikel heb gebaseerd.

Zodra alle ontwerp- en bouwactiviteiten zijn afgerond, start de meest onvoorspelbare fase van het project; de testuitvoering. Alle defects zijn geïntroduceerd en nu is het aan ons, testers, er zoveel mogelijk te vinden. Voor de start van de testuitvoering weten we niet hoeveel het er zijn, wanneer we ze zullen vinden en hoeveel tijd het gaat kosten om ze op te lossen. Natuurlijk is het niet noodzakelijk dat we alle defects vinden, maar zelfs een garantie dat we de meest ernstige vinden, kunnen we niet geven. Elke voorspelling kan de juiste zijn; ga dat maar eens plannen. In feite kunnen we sinds de invoering van ‘risk based’-testen binnen elk gegeven tijdsspanne een testrapport opleveren. In theorie zelfs na een uurtje, al is dat meestal niet het bericht waar de stakeholders van het project op zitten te wachten. Een goede aanpak voor een testuitvoering, gebaseerd op een rijke verzameling aan projecten, en bijbehorende mislukkingen, is de volgende:

• Een periode inplannen  van bijvoorbeeld drie weken om een eerste indruk te krijgen. Doel is om alle geplande testgevallen minimaal éénmaal uit te voeren. In deze fase gaan nog allerlei basale dingen mis; applicaties die nog niet beschikbaar zijn, login id’s die niet werken, omgevingen die nog niet gekoppeld zijn, et cetera. Neem voor deze fase de meeste tijd, omdat je hier de grootste problemen tegenkomt. Omdat je deze problemen meestal niet zelf kunt oplossen, kosten ze vaak veel tijd;
• Een periode inplannen van bijvoorbeeld twee weken om alle defects te hertesten, die gevonden zijn in de eerste fase en ook zijn opgelost. In de praktijk zal het oplossen en testen van bevindingen wat door elkaar lopen. Dat geeft niet;
• Een periode van nog eens drie weken inplannen om een ‘clean run’ uit te voeren. Vanaf de start van deze periode mogen er geen aanpassingen op het systeem meer worden uitgevoerd, om regressie te voorkomen.

Het voordeel van de clean run

Die laatste periode, en vooral het aspect van de ‘clean run’ is belangrijk. We kennen allemaal wel voorbeelden van waar dat mis kan gaan. Zo zal ik een voorbeeld geven uit mijn eigen historie; uit de tijd van de sequentiële tapebestanden. Voor een project moeten in de jaaropgaven van twee miljoen klanten de adresgegevens worden samengevoegd met de belastinggegevens. Alles was getest en liep goed. Er was echter een klein probleem; er miste een gegeven bij de belastinggegevens. OK, dit leek geen probleem. Bestand bijgewerkt, kijken of de gegevens er stonden en hup, naar de drukker. Alleen waren de twee bestanden nu niet meer in dezelfde volgorde gesorteerd; namelijk één op postcode en één op sofinummer. Tja, dat levert op twee miljoen records ongeveer vijftienhonderd hits. Resultaat: vijftienhonderd goede jaaropgaven in plaats van twee miljoen uit de printstraat van de drukker; een dure fout.

Die ‘clean run’ is dus belangrijk en wordt vaak niet voldoende serieus genomen. Ik geef de opdrachtgevers altijd aan dat het oplossen van een fout ook een change is. Alleen één die onder grotere druk tot stand komt. Daarom is een laatste testperiode zonder foutoplossing nodig. Geef dan ook duidelijk van tevoren aan, wat dat betekent. Als er toch een fout wordt gevonden in de laatste testperiode, betekent dat:

1. Of, dat de fout geaccepteerd wordt;

2. Of, dat er een volgende periode van herstel en (regressie)test nodig is.

Het eerste punt kan in sommige gevallen wel eens de voorkeuroptie zijn. Gelukkig hebben we tegenwoordig vaak een product risico analyse (pra) uitgevoerd, zodat de afspraken die daar gemaakt zijn, waarde aan de discussie kan bijdragen. Een goed uitgevoerde pra kan zeker bijdragen aan het nemen van de juiste beslissing. Bij projecten in problemen komen de geplande testperioden wel eens onder druk te staan. Dan wordt gevraagd waarom de software delivery niet in vier in plaats van zeven weken opgeleverd kan worden. Natuurlijk, je kunt ook alleen naar rechts kijken als je de straat oversteekt; dat kan vaak goed gaan. Dit is echter niet iets dat ik adviseer.

Wat dat betreft vergelijk ik testuitvoering wel eens met een berg zand. Je kunt er wat afhalen, maar het is nog steeds een berg zand. Daar kun je zelfs even mee doorgaan, maar wanneer houdt het op een berg zand te zijn? Dus op de vraag of ik in minder tijd kan testen is het antwoord meestal: ‘Ja, maar weet  je zeker dat je dat wilt?’ Over het algemeen hebben we geaccepteerd dat we niet alle fouten vinden. Hoe meer je test, hoe meer je er vindt. In elk geval: hoe minder je test, hoe meer fouten je  achterlaat en je hebt geen idee hoeveel en hoe ernstig ze kunnen zijn.

Combineren van testsoorten

Nog zoiets, kunnen we niet parallel gaan testen? Bijvoorbeeld de ‘system integration testing’ (sit) met de ‘user acceptance testing’ (uat) combineren, dan winnen we ook tijd. Goed idee, dan wachten er twee teams totdat de SIT defects zijn opgelost in plaats van één team. De meeste tijd wordt echter niet besteed in de uitvoering van testgevallen, maar in het vinden van de oorzaak en vervolgens het beleggen van de defects bij een oplossende partij.

Daarnaast moet ook de nodige aandacht worden besteed aan alle coördinerende activiteiten eromheen. Het wordt dan alleen maar complexer als er twee teams parallel testen. In de praktijk loopt de testuitvoering dus gewoon uit de planning bij parallel testen. Het netto effect is soms dat het meer tijd kost en in elk geval meer frustratie oplevert.

Beter plannen van de testuitvoering

In de meeste gevallen kunnen we best een kortere testuitvoering plannen. Maar is het testen dan ook eerder afgelopen? Kunnen we daarop sturen? Zullen we fouten eerder vinden en ook eerder oplossen? Het is mogelijk, maar je kunt het niet plannen. Als we van tevoren wisten welke fouten we zullen gaan vinden dan was de noodzaak van testen er niet. Dan zouden we van tevoren de defecten aan de ontwikkelaar vertellen en zou iedereen blij zijn. Helaas kunnen we niet voorspellen. Wat wel mogelijk is, is  om het aantal te vinden fouten te voorspellen.

Op een project waarop ik werkte, ontspon zich een discussie met de projectmanager van de ontwikkelaars over de planning. Elke week dat ik de planning inleverde van de  testperiode, betekende een extra week ontwikkeltijd voor zijn team en vice versa. Ik kreeg de vraag of ik die tweede run ook in één week kon uitvoeren. Nu had ik in een eerdere release ruim honderd fouten gevonden en deze release was vergelijkbaar qua grootte en functionaliteit. Dus mijn antwoord was: ‘Ik ga honderd fouten vinden, 25 in elke van de eerste drie weken. Hoe snel kun jij ze opgelost hebben?’ Dat was gebaseerd op de ervaring van de eerste release.

De duur van de testuitvoering wordt slechts gedeeltelijk bepaald door het aantal testgevallen. Een grotere invloed op de testuitvoering hebben echter de zaken eromheen zoals: defect management, omgevingbeheer, testers begeleiden (bij uat) en wijzigingen doorvoeren.

Agile versus Waterval

Hoewel tegenwoordig steeds meer Agile wordt ontwikkeld, gebruiken nog steeds veel projecten de klassieke watervalmethode. Maar ook in een Agile-omgeving zal dit probleem zich, met kortere tijdslijnen voordoen. Bijvoorbeeld na oplevering van een aantal sprints zal de behoefte om een uitgebreidere regressietest toenemen, met bijbehorende langere doorlooptijd. Agile is relatief nieuw en zo ook de ervaringen daarmee. Tijdens het voorjaarsevenement ga ik graag met het publiek de discussie aan omtrent Agile versus waterval.

Tot slot

Varianten op de bovenstaande beweringen en meningen gebruik ik al jaren. Over het algemeen met succes. Ik sluit het artikel  graag af met de volgende aanbeveling naar de lezer:

I hope you will consider above in your replanning sessions before you cut on test execution time. And find a way to get back to eight weeks. In full confidence of wise decisions.

 Erik Jansen, consultant bij Bartosz