Waarom de gebruikersacceptatietest niet past in een agile aanpak
"Zonder GAT kan je niet naar productie." In veel organisaties is het een vaste regel. Logisch in een watervaltraject, waar de GAT de sluitpost is van een lang ontwikkelproces. In een agile aanpak is het een probleem.
Waarom de GAT watervaldenken is
De klassieke gebruikersacceptatietest is een aparte fase aan het eind van het traject. Gebruikers doorlopen testscenario's in een omgeving die zo dicht mogelijk op productie lijkt, plannen worden opgesteld, en aan het einde volgt een formeel acceptatiemoment. Dat past bij een aanpak waarbij software gefaseerd wordt gebouwd en pas aan het eind aan de gebruiker wordt getoond.
Agile werkt anders. Iteratief ontwikkelen, voortdurende samenwerking, snelle feedback. Dat zijn de kernprincipes. Een grote acceptatietest aan het eind staat daar haaks op. Ook als je de GAT in een sprint verwerkt, los je het probleem niet op: je voert dan een mini-waterval uit binnen een sprint. Feedback komt te laat, user stories blijven doorslepen, en problemen worden ontdekt op het moment dat bijsturen duur is.
De gebruiker eerder betrekken
De oplossing is niet een andere vorm van GAT, maar het eerder en doorlopend betrekken van gebruikers bij het proces.
Key users die meedenken in refinements en three amigo sessies zorgen dat acceptatiecriteria scherp zijn voordat de bouw begint. Pair testing, waarbij een tester en gebruiker samen een functionaliteit doorlopen, levert directe feedback op. Mob testing, tegenwoordig ook wel ensemble testing genoemd, waarbij het hele team inclusief gebruikers samen een sessie doet, werkt goed voor complexe of risicogevoelige onderdelen. BDD, Behavior Driven Development, laat gebruikers, testers en ontwikkelaars samen acceptatiecriteria opstellen in begrijpelijke taal, zodat iedereen hetzelfde bedoelt voordat er ook maar één regel code is geschreven.
Al deze aanpakken brengen gebruikersfeedback naar het moment waarop het nuttig is: vroeg in het proces, als aanpassen nog weinig kost.
Alternatieven voor de gebruikersacceptatietest
Het loslaten van de GAT betekent niet dat er geen ruimte is voor gestructureerde gebruikersfeedback. Bughunts, sessies waarbij gebruikers actief op zoek gaan naar fouten, leveren waardevolle input op, zeker als ze vroeg in het traject worden ingepland. Pilots en beta-versies geven een kleine groep gebruikers de kans nieuwe functionaliteiten te testen voordat ze breed worden uitgerold. Usability testing, waarbij je gebruikers observeert terwijl ze opdrachten uitvoeren, legt problemen bloot die testscripts nooit opleveren.
Al deze vormen delen één principe: feedback ophalen op het moment dat je er nog iets mee kunt.
De GAT loslaten
De GAT is een traditie die haar oorsprong heeft in een aanpak die we bewust hebben verlaten. In een agile context levert vroege en doorlopende betrokkenheid van de gebruiker meer op dan een acceptatietest aan het eind. De gebruiker hoort niet in een aparte fase. Die hoort in het team.
