Dit artikel is eerder gepubliceerd op het TestNetNieuws Blog
Ik werk vooral in agile omgevingen: Als een user story voldoet aan de acceptatiecriteria, dan is het ‘done’. Dit is een regel die veelvuldig voorkomt bij agile/scrum in de ‘Definition of Done’. Echter, veel teams hebben moeite met het opstellen van deze acceptatiecriteria. Ja, het opstellen van goede acceptatiecriteria is lastig. Ik vraag me af: kost het niet te veel moeite ten opzichte van de baten? Leidt het opstellen van criteria niet af van het echte doel van een tester? Namelijk: Testen.
Verschillende methoden
Er worden manieren en methoden gezocht om het opstellen van de acceptatiecriteria te verbeteren. Een paar veel voorkomende voorbeelden:
Er worden manieren en methoden gezocht om het opstellen van de acceptatiecriteria te verbeteren. Een paar veel voorkomende voorbeelden:
Er wordt bijvoorbeeld een formule gebruikt, lijkend op het opstellen van een user story: Given… when…. Then….. Dit zijn pré conditie, situatiebeschrijving en gevolg. Dit is vaak de start voor de ontwikkelmethode ‘Behavior-driven development’ (Ref 1).
Ook is er de aanpak om in een groep van mensen door praktijksituaties te lopen en uiteindelijk verschillende situaties uit te werken in tabelvorm. Deze is dan het uitgangspunt om software te bouwen en automatische scripts te genereren om te testen. Men noemt dat ‘Specification by example’ (ref 2)
Er is de aanpak om met de Product Owner te gaan zitten en te bespreken wat hij goed genoeg vindt. Bijvoorbeeld met een checklist van kwaliteitseigenschappen die leidend kunnen zijn voor het gesprek. (ref 3)
Geautomatiseerd checkenDe eerste twee genoemde voorbeelden zijn vooral input voor geautomatiseerde uitvoering van testen. Over het algemeen wordt het geautomatiseerd testen beschouwd als ‘checken’. (ref 4)
Testability en acceptatiecriteria
Als je wat rond zoekt op internet, vind je veel definities van user stories en vaak de uitleg dat een belangrijk deel van de user stories de acceptatiecriteria zijn. Want als je niet weet hoe men het stukje software gaat accepteren, hoe kan je het dan testen? Vaak valt het onder de T(testable) van de mnemomic INVEST. (ref 5)
Als je wat rond zoekt op internet, vind je veel definities van user stories en vaak de uitleg dat een belangrijk deel van de user stories de acceptatiecriteria zijn. Want als je niet weet hoe men het stukje software gaat accepteren, hoe kan je het dan testen? Vaak valt het onder de T(testable) van de mnemomic INVEST. (ref 5)
Acceptatiecriteria van tevoren uitwerken
Over acceptatiecriteria en de uitwerking hiervan wordt best wel anders over gedacht. Bijvoorbeeld: moeten de acceptatiecriteria van tevoren worden vastgesteld, voordat een user story af is? Of mogen ze in de basis klaar zijn en dan verder uitgewerkt worden? (ref 6 & 7)
Over acceptatiecriteria en de uitwerking hiervan wordt best wel anders over gedacht. Bijvoorbeeld: moeten de acceptatiecriteria van tevoren worden vastgesteld, voordat een user story af is? Of mogen ze in de basis klaar zijn en dan verder uitgewerkt worden? (ref 6 & 7)
Focus op acceptatiecriteria in agile zonder en met testersIk zie de voordelen van, en de toepassing van acceptatiecriteria in een ontwikkeltraject om een user story helder te krijgen. Waar het vaak op uitdraait is dat het controleren van acceptatiecriteria dan ook het enige testfocus is in veel projecten. Het testen of de software werkt zoals is opgesteld. Dit komt vaak voor als de leden van een team nog nooit met een tester hebben gesproken en naar hun idee de testen uitwerken naar unit tests. Overigens komt nog vaker voor dat er helemaal geen acceptatiecriteria worden gebruikt, maar gewerkt wordt vanuit de logische gedachte van de developer om deze testen uitgewerkt.
Het lijkt erop dat de meest geaccepteerde manier van testen in de agile wereld ‘checken’ is. Dit omdat agile teams vooral een technisch oorsprong hebben en de focus ligt bij hen op het ontwikkelen en schrijven van code. Ontwikkelaars leren op school en van elkaar dat het checken van software gelijk staat aan testen.
Bij teams waar wel een tester wordt betrokken zie je dat er meer focus komt op de acceptatiecriteria, omdat dit voor veel testers het uitgangspunt is voor hun werk. Als er te weinig focus is op goede specificaties in een team, is vaak de tester die dit naar voren brengt en probeert dit binnen een team onder de aandacht te brengen.
De problemen met acceptatiecriteriaDe focus zou niet op acceptatiecriteria moeten liggen met als belangrijkste redenen:
Waterval promotendJe kan zeggen, doordat je probeert acceptatiecriteria van tevoren vast te stellen, dat je eigenlijk bezig bent met een soort van waterval. Wat is goed genoeg om de user story af te krijgen? Bijna altijd geldt voor een periode van een sprint hetzelfde als bij grote waterval 
projecten: voortschrijdend inzicht komt met de tijd en te gedetailleerde criteria worden aangepast in de loop van de tijd. Het aanpassen van criteria door uit ervaring te leren is goed, maar te uitgewerkte criteria was zonde van de tijd. Natuurlijk worden criteria aangepast in veel teams, maar het komt ook voor dat iets niet gedaan wordt tegen beter weten in: ‘Omdat het niet in de acceptatiecriteria staat’.
projecten: voortschrijdend inzicht komt met de tijd en te gedetailleerde criteria worden aangepast in de loop van de tijd. Het aanpassen van criteria door uit ervaring te leren is goed, maar te uitgewerkte criteria was zonde van de tijd. Natuurlijk worden criteria aangepast in veel teams, maar het komt ook voor dat iets niet gedaan wordt tegen beter weten in: ‘Omdat het niet in de acceptatiecriteria staat’.
Onbewuste vooringenomenheid van bevestiging (confirmation bias)
De woorden zeggen het al: we kunnen deze software accepteren als het voldoet aan deze criteria. Onze uitwerking van de software en het testen van de software zal bij het gebruik van acceptatiecriteria vooral gericht zijn op het valideren van de juiste werking. Het is zo dat onze (ja ook van jou, maar ook van je teamleden) hersenen de acceptatiecriteria zien als een bevestiging van wat gedaan moet worden. Focus op goed werkende software. En hier is iets mis mee. Een onbewust proces in onze hersenen zorgt ervoor (in min of meerdere mate) dat we niet meer bezig zijn om te bedenken welke situaties er van toepassing kunnen zijn om de software totaal in de soep te laten lopen. Dit noemen we de ‘confirmation bias’ (ref 8).
De woorden zeggen het al: we kunnen deze software accepteren als het voldoet aan deze criteria. Onze uitwerking van de software en het testen van de software zal bij het gebruik van acceptatiecriteria vooral gericht zijn op het valideren van de juiste werking. Het is zo dat onze (ja ook van jou, maar ook van je teamleden) hersenen de acceptatiecriteria zien als een bevestiging van wat gedaan moet worden. Focus op goed werkende software. En hier is iets mis mee. Een onbewust proces in onze hersenen zorgt ervoor (in min of meerdere mate) dat we niet meer bezig zijn om te bedenken welke situaties er van toepassing kunnen zijn om de software totaal in de soep te laten lopen. Dit noemen we de ‘confirmation bias’ (ref 8).
‘Old school’ risico’sWaarom beginnen we niet bij de risico’s? Dan praat je niet over hoe het wel zou moeten werken, maar dan ga je nadenken in welke situaties de software fout zou kunnen gaan.
Geen risico’s? Niet testen!
In een discussie hierover met een collega kwamen de woorden ‘old school’ naar boven. En ja, het is al een tijdje in de test wereld zo dat veel testen een basis vinden in risico’s. Ook in traditionele proces-gebaseerde methoden zoals TMap of ISTQB begint men met de risico’s als basis voor de verdere uitwerking van een teststrategie. Maar ook bij de testschool ‘Context Driven Testing’ (ref 9)wordt er vanuit risico’s gedacht. Zowel product-, proces- als projectrisico’s.
Praten vanuit risico’s over testen helpt ook de rest van je team nadenken over de foutpaden en het bepalen van testdiepgang en prioriteit van wat er bekeken moet worden.
Tester, maak je niet druk over acceptatiecriteriaEr is iets wat je als tester zou moeten realiseren: je hebt geen acceptatiecriteria nodig om te testen (ref 10). In plaats van mee te gaan met de agile trend om in user stories de acceptatiecriteria te beschrijven, zouden we vanuit testperspectief altijd moeten praten over risico’s. Teams vergeten wat voor risico’s er zijn en nemen deze niet mee in het testen van de software. Verder leidt het gebruik van acceptatiecriteria vaak tot het van tevoren maken van specificaties, wat een watervalachtig karakter kan krijgen. Hierbij worden voortschrijdend inzicht en de ideeën die hieruit ontstaan worden genegeerd, of in het lichtste geval gelimiteerd tot ‘iets om later uit te werken’.
Referenties
- Behavior driven development – https://en.wikipedia.org/wiki/Behavior-driven_development
- Specification by example – https://en.wikipedia.org/wiki/Specification_by_example
- Lijst van kwaliteits eigenschappen – http://thetesteye.com/blog/2011/11/software-quality-characteristics-1-1/
- Testing and checking refined – http://www.satisfice.com/blog/archives/856
- INVEST – https://en.wikipedia.org/wiki/INVEST_(mnemonic)
- Why Acceptance Criteria Are Needed Before User Stories Can Be Relatively Sized –https://www.scrumalliance.org/community/articles/2014/june/why-acceptance-criteria%E2%80%9D-is-needed-before-user-sto
- User Story Acceptance Criteria Versus the Definition of Done –https://www.scrumalliance.org/community/articles/2015/february/user-story-acceptance-criteria-vs-definition-of-do
- Confirmation bias – https://en.wikipedia.org/wiki/Confirmation_bias
- You don’t need acceptance criteria to test – http://www.developsense.com/blog/2015/02/very-short-blog-posts-26-you-dont-need-acceptance-criteria-to-test/
- Context Driven Testing – http://context-driven-testing.com/
