Die ‘clean run’ is dus belangrijk en wordt vaak niet voldoende serieus genomen.
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:
- Of, dat de fout geaccepteerd wordt;
- Of, dat er een volgende periode van herstel en (regressie)test nodig is.
Het eerste punt kan in sommige gevallen wel eens de voorkeursoptie zijn. Gelukkig hebben we tegenwoordig vaak een Product Risico Analyse (PRA) uitgevoerd, zodat de afspraken die daar gemaakt zijn, 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 dan is het 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.
“Wat dat betreft vergelijk ik testuitvoering wel eens met een berg zand. Je kunt er wat afhalen, maar dan is het nog steeds een berg zand”
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 die ik op de planning van de testperiode inleverde, 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 veel Agile wordt ontwikkeld, gebruiken nog steeds 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.
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, die ik ook voor mijn zomervakantie voor het project uit het begin van dit artikel heb achtergelaten:
