Is waterval testen de redding van Scrum?

Waterval testen, oftewel eerst testen voorbereiden en vastleggen en veel later uitvoeren, hoort niet bij Scrum of Agile. Toch doe ik het. En vele testcollega's met me. Ik moet wel. We moeten wel. Het is de enige manier waarop we in een Scrum omgeving enige garantie op kwaliteit kunnen geven. Hoe is dit gekomen? Waar is het misgegaan? Of is er wel iets mis gegaan? Omdat deze blog niet alleen door ervaren testers gelezen wordt, eerst wat waterval testen informatie. De testvoorbereiding en testuitvoering is ontstaan in een manier van werken, waarbij ontwikkelaars weken of maanden achter elkaar programmeerden. Nadat een product "af" was, werd het op een testomgeving gezet. En daarna was het voor de ontwikkelaars wachten op feedback van de testers. Met een duidelijk verzoek: geef ons deze feedback zo snel mogelijk. Om dit voor elkaar te krijgen, is de testvoorbereiding ontstaan. Van tevoren werd nagegaan welke knoppen geklikt moesten worden, welke velden ingevoerd moesten worden en welke waardes hierin moesten staan. En wat hiervan het eindresultaat moest zijn. Dit werd allemaal vastgelegd in een zeer gedetailleerd testscript. Tijdens de testuitvoering had je hierdoor geen voorbereiding meer nodig. Een extra voordeel was, dat het script zo uitgebreid was, dat werkelijk iedereen het uit kon voeren, zelfs als je totaal geen kennis had. Gewoon doen wat er staat en kijken of je ziet wat er staat. Met als einddoel: heel veel tijd steken in de testvoorbereiding, zodat de testuitvoering snel kan worden uitgevoerd. Toen kwam er een behoefte aan kortere opleverperiodes. Om het bij Scrum termen te houden: sprints. Vaak opleveren, zodat de klant eerder resultaat ziet en hierdoor ook beter en eerder bij kan sturen. Maar er was een groot nadeel: de huidige manier van testen was hier niet geschikt voor. De sprints waren te kort om zulke lange testvoorbereiding uit te voeren. Niet voor niets werd bijna tegelijkertijd een streven ingevoerd naar veel minder documentatie. De oplossing: testen zonder testvoorbereiding. De testuitvoering werd misschien wel langer. Maar doordat veel meer tijd werd bespaart door het weglaten van de testvoorbereiding, was de totale testtijd veel korter. En een kortere totale testtijd paste veel beter in de nieuwe flink kortere sprints. Maar wat gebeurde er? Te vaak werden de sprints alsnog kleine watervallen. De ontwikkelaars namen een groot deel van de sprint om 1 story te bouwen. Met als gevolg dat vlak voor het einde van de sprint het meeste werk pas opgeleverd werd naar de testomgeving. De wens "Geef ons zo snel mogelijk feedback" werd alleen maar sterker. Tenslotte moest het werk nu niet over 2 maanden, maar over 2 dagen afgerond zijn. Dus om enige kans te hebben de sprint te halen, moest de testuitvoering razendsnel. Een razendsnelle testuitvoering was en is niet mogelijk zonder testvoorbereiding. Dus grijp ik, en vele andere testers met mij, terug naar de testvoorbereiding en het testscript. En maken we de langere testdoorlooptijd maar zo passend mogelijk. Hoe het zou moeten werken? Binnen een goed ingedeelde sprint wordt door de sprint verspreid regelmatig werk opgeleverd. Terwijl de tester dit werk test, ontwikkelt de ontwikkelaar het volgende werk. De tester heeft zo een zeer regelmatig aangeboden hoeveelheid werk. Aan het eind van de sprint is er vervolgens niet opeens een grote hoeveelheid. Nee, er is een behapbare hoeveelheid werk, dat makkelijk in de laatste dagen van een sprint getest kan worden. Zo kom je op een van de grootste struikelblokken van Scrum: het kleiner maken van story's. Om dit voor elkaar te krijgen, moeten grote story's, met de grootte van (bijna) een sprint, kleiner gemaakt worden. In de eerste plaats zijn hier vaardigheden voor nodig, waar de gemiddelde ontwikkelaar niet over beschikt. In de tweede plaats staat ook een ontwikkelaar vaak onder druk. Als Scrum niet goed loopt, zijn er vaak managers, scrum masters, enz. die zeggen dat er meer werk sneller moet worden opgeleverd. De snelste manier van opleveren voor een ontwikkelaar is heel simpel: geef hem een grote klus en wacht tot die klaar is. Dit is volledig in tegenspraak met het opsplitsen van story's. Het opsplitsen van story's zorgt ervoor dat de ontwikkelaar minder snel ontwikkelt, meer tijd kwijt is en zelfs dubbel werk oplevert. De ontwikkelaar gaat dus trager werken en minder opleveren. Waarom je het dan toch moet doen? Omdat het team sneller en beter gaat werken. Omdat het team naast elkaar kan gaan werken en niet op elkaar hoeft te wachten. Nee, waterval testen is niet de redding van Scrum. Het streven om hiervan los te komen is volledig terecht. Maar waterval testen is een waardevolle reddingsboei in het woelige water dat men Scrum noemt, maar niet Scrum is. Zolang de snelheid van een individu nog blijft gaan boven de snelheid van het team.