Noem het een ode. Noem het een lofzang. Noem het nostalgie. Hoe je het ook noemt: deze blog wil de door bijna de hele ICT wereld vergeten waterval-methode een hart onder de riem steken. Want laten we eerlijk zijn, zo slecht is waterval nog niet. Zeker niet als je het vergelijkt met de manier waarop agile in veel gevallen wordt ingevuld. De agile-adapt die ik ben, zal vertellen waarom we onze oude schoenen niet zomaar weg moeten gooien.
Er zijn een tweetal aspecten van waterval die in vergelijk met het werken in sprints van bijvoorbeeld twee weken duidelijke voordelen hebben ten opzichte van de iteratieve werkmethode. Zelfs als de agile werkwijze optimaal wordt ingevuld. Laten die aspecten nou net van groot belang zijn voor de tester!
Documentatie
De excuus-Truus van het agile manifesto: werkende software krijgt voorrang boven het vastleggen van documentatie. In de praktijk betekent dit dat requirements zelden goed vastgelegd worden en in veel gevallen niet verder komen dan een foto van het whiteboard. Zoals bekend is de voorbereidingsfase voor een tester minstens net zo belangrijk als een goede testuitvoer. En wat is daarvoor de basis? Juist, de documentatie. Het tegenargument is meestal dat de documentatie in waterval de dikte van een telefoonboek heeft en uiteindelijk sterk verouderd is op het moment dat er wordt opgeleverd. Is dat argument wel valide?
Ik denk het niet. Agile teams wisselen na verloop van tijd van samenstelling. Over langere tijd bekeken is de samenstelling van het team dan totaal anders dan bij sprint 0. Als er door dat team dan niet of nauwelijks is gedocumenteerd, is er dus geen vastlegging en kennis van een groot deel van het systeem. Verouderd of niet: bij waterval heb je in ieder geval nog de basis. Daarbij is het ook nog eens zo dat teams in waterval minder snel rouleren omdat het om een project gaat met een duidelijke kop en staart. Het vangnet is bij waterval steviger dan bij agile.
Gestructureerd testen
In de vorige paragraaf kwam de voorbereidingsfase (TMap) van testen al ter sprake. Het werken in sprints biedt op zich wel ruimte om daar tijd aan te besteden. Ook de Specificatie en Afronding zijn in beeld. Maar...
Het leuke van agile en daarmee het werken in sprints, is de dynamiek. Hoewel de voorspelbaarheid van de velocity voor Scrum masters hoog op het verlanglijstje staat, wordt de prettige hectiek en het anticiperen daarop veroorzaakt door de waan van de dag die op gezette tijden als een trein het team binnen dendert. Dat heeft tot gevolg dat gestructureerd testen veel te vaak niet aan de orde is, zo niet onmogelijk. Documentatie die niet op orde is, helpt daar overigens niet aan mee.
Ook hier wint waterval. Juist doordat de oplevering van software op zich laat wachten is er alle tijd voor alle fasen van een gestructureerde testaanpak. Zorgen dat de testomgevingen werken, test data ruim op tijd is aangevraagd en testscenario’s door de business zijn goedgekeurd. Heerlijk toch?
Samen een drankje drinken
Wat moeten we met dit inzicht? Geen enkele methodiek is perfect. Waterval niet. Maar Agile ook niet. En een combinatie van de twee (“wet agile” in de literatuur) ook niet. Wat ik wel zie is dat ICT'ers en projectleiders in waterval omgevingen hun best doen om agile elementen aan hun proces toe te voegen. Maar andersom? Hmmm. Misschien is het goed als agile zijn vriend waterval eens voor een drankje uitnodigt en luistert naar de wijze lessen van een methode die volwassen is en nog lang niet afgeschreven!
Martin is als testconsultant werkzaam bij PTWEE en deelt zijn meestal kritische blik op de testwereld (onder andere) via dit blog.
