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.

Agile testen is meer dan stories testen

Bij Agile testen staan stories (al of niet user-stories) vaak centraal. En dat is terecht. Het is en blijft het doel om te controleren of gemaakte wijzigingen goed doorgevoerd worden. Maar Agile testen is meer. Er is al de discussie over testen v.s. toetsen. Niet alleen specificaties controleren, maar als tester ook verder kijken. Toch zie je dat veel tester binnen Agile nog een stap verder gaan. Ze gaan niet voor goed gebouwde wijzigingen. Ze gaan voor kwaliteit. En dat is een trend waar ik me graag bij aansluit. Naar mijn mening wil een goede Agile tester niet alleen goed testen. Een goede Agile tester wil kennis opbouwen. En voornamelijk op twee gebieden. Het eerste meest logische gebied is de testtools. Om de kwaliteit te bewaken, en soms om het testproces ook in kwaliteit te verbeteren, wil een Agile tester het beste uit zijn of haar tools halen. Het leren van de tools en het experimenteren met tools is iets wat elke Agile tester als streven moet hebben. Hierbij gaat het niet alleen om automatisch testen, maar ook om bijvoorbeeld tools rond testomgevingen en bevindingenregistratiesystemen. En ja, de realiteit slaat soms toe. Je kan niet alles leren. Soms moet je vertrouwen op de kennis van anderen. Maar de wil moet aanwezig zijn. Het tweede gebied is eigenlijk heel logisch, maar komt vaak niet het eerste op. Een goede Agile tester moet domeinkennis en softwarekennis opbouwen. Een Agile tester mag niet alleen afhankelijk zijn van de input van de storyschrijver om goed te kunnen testen. Op basis van eigen kennis (al of niet vastgelegd in documentatie) moet hij/zij kunnen bepalen of er geen paden, varianten, schermen, enz. vergeten zijn. Kennis over hoe de software werkt, welke gegevens vaak gebruikt worden, welke schermen vaak gebruikt worden, welke schermen op elkaar lijken, welke schermen dezelfde gegevens gebruiken, enz. Maar ook weten wat veel voorkomende opdrachten zijn binnen het domein. Wat voor facturen worden vaak gestuurd en wat voor facturen minder. Wat voor klanten zijn er? Zijn deze in duidelijke groepen in te delen? Wat zijn de grootste klanten? Deze informatie kan gebruikt worden om tot goede testdata te komen. Testdata, die lijken op de praktijk en daarmee een goed beeld geven van de kwaliteit. Daarnaast is te merken, dat veel testers deze kennis al gaan gebruiken bij de backlog refinement, waardoor ook bijvoorbeeld developers en storyschrijvers ervan kunnen profiteren. Scrum en Agile streven beiden niet naar goed opgeleverde wijzigingen, maar naar een kwalitatief opgeleverd product. Om dit te bereiken streven beiden naar verbetering in proces. Hoewel specialiteiten niet ontkent worden, wordt vooral de onderlinge samenwerking (ongeacht functie) centraal gesteld. Een goede Agile tester gaat hierin mee door niet alleen te kijken naar kwaliteitsbewaking op korte termijn (testen en toetsen), maar op lange termijn (tools en processen). En door zijn/haar kennis uit te breiden en later in te zetten om zowel de inhoud van de story als de uitwerking in code en testuitwerking beter te krijgen.