Acceptatiecriteria opstellen: uitleg en praktische voorbeelden

Wat zijn acceptatiecriteria?

Acceptatiecriteria zijn concrete afspraken waaraan een onderdeel van je software moet voldoen om geaccepteerd te worden. Ze helpen je team om het gewenste gedrag te begrijpen, te bouwen en te controleren.

Bij een kortingscode kun je bijvoorbeeld afspreken:

• Code WELKOM10 geeft 10% korting op niet-afgeprijsde producten.
• Afgeprijsde producten krijgen geen extra korting.
• Een verlopen code geeft geen korting. De klant ziet: ‘Deze kortingscode is verlopen.’

Dit zijn voorbeeldregels. Jullie webshop kan natuurlijk andere afspraken hebben. Waar het om gaat: je kunt samen naar deze criteria kijken en bespreken of dit inderdaad de bedoeling is.

Dat is al een stuk bruikbaarder dan: ‘De kortingscode moet goed werken.’ Al zal niemand daar tijdens het overleg bezwaar tegen maken.

Het probleem zit vaak in wat je niet opschrijft

De meeste misverstanden ontstaan zonder dat iemand onduidelijk probeert te zijn. Mensen vullen ontbrekende informatie aan met wat ze zelf weten.

De product owner kent de kortingsvoorwaarden al jaren. Voor hem spreekt het vanzelf dat aanbiedingen zijn uitgesloten. De developer werkt sinds vorige maand aan de webshop en heeft die afspraak nog nooit gehoord. De tester heeft vooral gekeken of geldige en ongeldige codes goed worden afgehandeld.

Iedereen doet zijn werk. Toch gaat het mis!

Daarom heeft het weinig zin om na de demo alleen te vragen wie iets vergeten is. Interessanter is: welke vraag hadden we eerder kunnen stellen? Bijvoorbeeld: ‘Voor welke producten geldt deze korting eigenlijk?’

Goede acceptatiecriteria ontstaan vaak uit precies dat soort eenvoudige vragen.

Van ‘werkt goed’ naar een afspraak waar je iets mee kunt

Je hoeft geen bijzonder schrijftalent te hebben om acceptatiecriteria op te stellen. Het helpt vooral als je merkt wanneer een zin nog te veel ruimte laat voor eigen invulling.

Neem deze voorbeelden:

• Voor: De korting wordt correct verwerkt.
• Na: Code WELKOM10 geeft 10% korting op niet-afgeprijsde producten.
• Voor: Een verkeerde code geeft een foutmelding.
• Na: Bij een onbekende code blijft het bestelbedrag gelijk en verschijnt: ‘Deze kortingscode herkennen we niet.’
• Voor: De klant kan maar één code gebruiken.
• Na: Na het toepassen van een geldige code kan de klant geen tweede code toevoegen. De eerste code kan wel worden verwijderd.

Vooral die laatste is aardig. ‘Maar één code’ lijkt een heldere afspraak. Tot een collega vraagt: ‘En als ik per ongeluk de verkeerde heb ingevuld?’ Dan blijkt dat je ook iets moet afspreken over verwijderen of vervangen. Je bent nog geen regel code verder, maar begrijpt de gewenste oplossing al beter.

Leg eens een winkelmandje op tafel

Blijft het gesprek wat abstract? Pak er een concreet voorbeeld bij. Een klant koopt een trui van €60 en een afgeprijsde broek van €40. De verzendkosten zijn €5. Daarna vult hij WELKOM10 in. Wat betaalt hij? 

Volgens onze voorbeeldregels krijgt alleen de trui 10% korting. Dat is €6. Als de verzendkosten gelijk blijven, komt de bestelling uit op €99. ‘Wacht,’ zegt iemand. ‘Vanaf €100 bezorgen we toch gratis?’

Kijk, nu wordt het interessant. Want telt daarvoor het bedrag vóór of ná de korting? En tellen afgeprijsde producten wel mee voor gratis verzending, ook al krijgen ze geen extra korting? Met één winkelmandje ontdek je ineens meerdere afspraken. Daar heb je geen uitgebreide presentatie voor nodig. Een paar bedragen op een scherm zijn genoeg.

• De product owner verduidelijkt de commerciële regels.

• De developer kijkt hoe de berekeningen samenhangen.

• De software tester bedenkt situaties waarin de uitkomst kan afwijken.

Zo gebruik je de kennis die al in je team aanwezig is.

Stel vooral de vraag: ‘En wat gebeurt er nét onder die grens?’

Sommige afspraken zijn bijna een uitnodiging voor een test. Bijvoorbeeld:Bij een bestelling vanaf €50 krijgt de klant €5 korting.Dan wil je weten wat er gebeurt bij €49,99, precies €50 en €50,01. Dat heet binnen testen grenswaardenanalyse: je onderzoekt waarden rond een grens, omdat daar gemakkelijk fouten ontstaan. Maar voordat je gaat testen, moet de afspraak zelf helder zijn. Welke €50 bedoelen we? Met of zonder verzendkosten? Vóór of ná andere kortingen?

En wat gebeurt er als de klant na het toepassen van de code een product uit zijn mandje haalt? Dat zijn geen vergezochte situaties. Mensen veranderen voortdurend hun bestelling. Het zou prettig zijn als de korting dan gewoon meerekent.

Moeten we nu iedere uitzondering vooraf bedenken?

Je voelt misschien al een overleg aankomen waarin iemand na drie kwartier vraagt wat er gebeurt als de klant op schrikkeldag vanuit Australië bestelt. Gelukkig hoeft niet iedere wijziging een boekwerk te worden. Begin met de afspraken waarbij een misverstand belangrijke gevolgen heeft of gemakkelijk ontstaat. Bij korting zijn dat bijvoorbeeld de berekening, uitgesloten producten en het combineren van codes.

Is een regel nog niet besloten? Schrijf die dan op als open vraag. ‘Nog uitzoeken of verzendkosten meetellen’ is eerlijker en bruikbaarder dan een aanname die toevallig als definitieve afspraak in de user story belandt. Tijdens het bouwen en testen ontdek je soms nieuwe dingen. Dan bespreek je die en pas je de criteria aan. Het doel is dat je voldoende duidelijkheid hebt om verantwoord verder te werken.

Vijf vragen voor jullie volgende bespreking

Wil je hiermee aan de slag? Stel bij de volgende user story eens deze vragen:

1. Wat moet er gebeuren? Beschrijf het gedrag dat je verwacht.
2. Kunnen we een concreet voorbeeld geven? Pak een bedrag, invoer of herkenbare situatie.
3. Wanneer mag het juist niet? Bespreek voorwaarden en uitzonderingen.
4. Wat gebeurt er als iets misgaat? Denk aan verkeerde invoer of een systeem dat niet reageert.
5. Waar denken we nog verschillend over? Geef twijfels de ruimte voordat iemand gaat bouwen.

Die laatste vraag levert vaak het beste gesprek op. Zeker als iemand zegt: ‘O, ik dacht juist dat…’ Dan heb je een verschil ontdekt dat anders misschien tot de demo verborgen was gebleven.

Wat heeft dit met TMap te maken?

Binnen TMap werk je samen aan kwaliteit. Acceptatiecriteria helpen om dat gewenste gedrag concreet te maken. Ze zijn een belangrijke basis, al vertellen ze niet automatisch alles over de kwaliteit. Ook beveiliging, prestaties en beheer kunnen aandacht nodig hebben, afhankelijk van de wijziging. Wil je leren hoe je die afwegingen samen met je team maakt? In de e-learningTMap® Quality for cross-functional teams leer je meer over deze manier van werken.