User stories, een handreiking aan testers

Te vaak ging het mis. Het ontwerp nam te veel tijd in beslag. Of er was te veel documentatie. Ik hoor het de klant nog zeggen: 'dit is goed werkende software, maar dit heb ik net niet bedoeld'. Samengevat klinkt het briljant: niet opschrijven wat de software moet doen, maar wat de klant wil. Maar hoe schrijf ik dat op? Nog meer requirements? En hoe test je een klantwens? In deze blog een korte handreiking aan testers over user stories.

Waarom user stories?
Software moet aan bepaalde behoeften voldoen. Er is dus een need. Dat is waar user stories over gaan. Wanneer je een user story schrijft, beschrijf je ruwweg een behoefte van een gebruiker. Iets wat de gebruiker nodig heeft in zijn dagelijks werk. Met andere woorden, ook al zou je nooit een stukje software voor de gebruiker bouwen, de behoefte blijft bestaan. User stories zijn makkelijk te begrijpen. Ze zijn geschreven in de taal van de gebruiker. En ze zijn kort. Of althans, ze behoren kort te zijn. Daarom is het een goed gebruik om de user story op een kaart te schrijven.

Een user story is zeker geen use case. Of nog duidelijker gezegd: geen variant van een use case en ook geen alternatief. Een use case beschrijft het gedrag van de software om aan de behoefte van de gebruiker te voldoen. Use cases zijn ontstaan om alle mogelijke manieren waarop een gebruiker (actor) een doel kan bereiken, gestructureerd te beschrijven. Als een softwareontwikkelaar de use case leest, dan moet duidelijk zijn wat de software moet doen om aan de behoefte van de gebruiker tegemoet te komen. Dat impliceert een aanzienlijk niveau van detail en een duidelijke en ondubbelzinnige beschrijving. De interactie tussen een of meerdere actoren en het systeem wordt dus beschreven in een use case. Die actoren kunnen dus ook andere systemen zijn. Uit deze beschrijving van een use case kun je al voorzichtig de conclusie trekken dat er een flinke stapel documentatie in het verschiet ligt.

Misschien denk je nu wel: met een use case kan een ontwikkelaar direct aan de slag, maar dat lukt toch niet met een user story? Zijn er niet veel te weinig details bekend? Je hebt gelijk. En dat is nu juist het punt. Een user story is geen vervanging van een document met requirements. Het is een trigger om een gesprek op gang te brengen tussen de betrokkenen over de relevante requirements. En geen eenmalig gesprek, maar een doorlopend gesprek. Want zij die de software willen gebruiken moeten communiceren met hen die de software willen maken.

De drie C’s
Hoe een user story tot stand komt, wordt vaak samengevat met de drie C’s.
1. Card
User stories staan op een kaart. De user story staat op de voorkant, de acceptatiecriteria op de achterkant.
2. Conversation
De kaart is de aanleiding om een gesprek over de requirements te hebben tussen teamleden, product owner, stakeholder, gebruikers, klanten et cetera.
3. Confirmation
De user story helpt het team om in overleg met de product owner te bepalen wanneer het werk voor deze story af is. Dit zijn de acceptatiecriteria die in test cases worden omgezet om te testen of al het nodige werk is gedaan.

Card
Een user story is een vereenvoudigde beschrijving van een requirement of feature geschreven in de volgende vorm: Als wie, wil ik wat zodat waarom. Of in het Engels: As a who I want what so that why. Dat format is flexibel. We kunnen het daarom ook zo schrijven: As a user role, I want/need/can/etc goal so that reason.
Meestal heeft de product owner of klant al een bescheiden lijst met user stories of wensen. Dan is het zaak om te komen tot een voor alle partijen gewenst detailniveau van de user stories. Een tester kan in deze fase van het proces al van toegevoegde waarde zijn. In meerdere korte iteraties kan het team user stories gedetailleerder verwoorden. Misschien werkt een voorbeeld verhelderend:

Als frequent flyer wil ik een vlucht boeken
• Als frequent flyer wil ik een vlucht boeken met mijn gespaarde punten.
• Als frequent flyer wil ik een vlucht die ik vaak maak opnieuw boeken.
• Als frequent flyer wil ik een upgrade aanvragen.
• Als frequent flyer wil ik kiezen uit geselecteerde aanbiedingen van vluchten.

Het kunnen boeken van een vlucht is nu een grote user story geworden, een epic, die meerdere kleinere user stories omvat.

Een goede user story staat niet alleen op een kaart, maar voldoet allereerst aan het INVEST-principe. INVEST is een acroniem dat staat voor:
• Independent
Een story moet onafhankelijk zijn van andere stories. Onafhankelijke stories kun je afzonderlijk prioriteren en plannen. Dat geldt ook voor het ontwikkelen en testen. Minimaliseer dus de afhankelijkheden.
• Negotiable
Over de story moet overleg mogelijk zijn met de product owner. Stories zijn geen contracten. Daarnaast bevatten ze niet te veel details, want te veel details geven de indruk dat alles al bekend en compleet is en er geen aanleiding is om verder te praten. Flexibiliteit geeft de mogelijkheid om aan te passen wat wel en wat niet geïmplementeerd moet worden.
• Valuable
Een story moet waardevol zijn voor de business. Zo wordt voorkomen dat er features worden ontwikkeld die uiteindelijk door niemand gebruikt worden. Herschrijf stories die waardevol zijn voor de ontwikkelaar naar een story waarin de waarde voor de klant centraal staat.
• Estimatable
Een story wordt zo geschreven dat het team kan inschatten hoeveel werk ermee behelst is. De story is het uitgangspunt bij het plannen. Ontbreekt er technische kennis of domeinkennis, dan is inschatten lastig. Dat geldt eveneens voor een story die te groot is.
• Small
Grote stories zijn moeilijk te in te schatten en moeilijk te plannen. Houd een story daarom klein. Klein betekent niet zo klein mogelijk. Het gewenste detailniveau is per feature verschillend. Splits stories indien nodig op basis van CRUD-acties.
• Testable
Het testen van een story toont aan dat aan de verwachtingen van de klant is voldaan. Verificatie is mogelijk. Dus niet ‘de pagina moet snel laden’, maar ‘de pagina moet laden binnen twee seconden’.

Conversation
Het gesprek tussen de teamleden en de product owner wordt op gang gebracht door de user story. De focus wijzigt dus van schrijven naar praten. Software kun je ontwikkelen op basis van een document met specificaties en requirements. Maar is dat wat is opgeschreven ook daadwerkelijk wat de klant wil? Woorden, en inherent daaraan tekst, zijn immers ambigu en kunnen op verschillende manieren geïnterpreteerd worden. Juist in een doorlopend gesprek moeten en kunnen alle vragen gesteld worden die nodig zijn om precies duidelijk te krijgen wat de behoefte van de klant is. Voordat de inhoud van een spint wordt bepaald, vindt dit gesprek vaak plaats in een backlog refinement-sessie. Dat is niet verkeerd, maar het betreft een ongoing process, dus beperk het niet tot een sessie. Volgens het principe van de last responsible moment kunnen de benodigde details kort voor implementatie worden opgehelderd.

Confirmation
Op de achterkant van de kaart waar de user story op staat, worden de acceptatiecriteria geschreven. Dit is ook de plaats om extra details en verwachtingen op te schrijven. In de acceptatiecriteria van een betaling met een creditcard kan iets komen te staan over de soorten creditcards, de lengte van het nummer, werking met een geblokkeerde card, werking met een verlopen card et cetera. Probeer het noemen van een oplossing te vermijden. Schrijf dus liever ‘de gebruiker kan een account kiezen’ dan ‘de gebruiker kan een account kiezen middels een drop-down’.

Acceptatiecriteria zijn een set statements die zowel functionele als non-functionele eisen bevatten waaraan de ontwikkelde software moet voldoen. Op de statements moet een duidelijk ok / niet ok antwoord te geven zijn. We spreken hier van conditions of satisfaction.
Een tester zal zijn best doen om de acceptatiecriteria zo helder en specifiek mogelijk te krijgen. Het doordenken van de behoefte van de gebruiker is een taak voor de tester. Want als hij weet wat de product owner eist, kan hij testen of de user story done is. Reeds bij het opstellen van de acceptatiecriteria kan de mogelijkheid van testautomatisering in het oog worden gehouden. Zo kan de tester gelijktijdig met het ontwikkelen zijn testcases bouwen.

De tester
Een goede tester wacht dus niet tot de user story met acceptatiecriteria is ontwikkeld voor hij aan de slag gaat met testen. Al vroeg in het proces is er ruime gelegenheid om als tester van toegevoegde waarde te zijn. Bijvoorbeeld bij het opdelen van user stories en bij het opstellen van de acceptatiecriteria. Misschien is een onderonsje met de product owner nodig om duidelijk te maken dat een tester die vroeg in proces betrokken is, later in het proces tijd bespaart. Een tester heeft een unieke positie tussen ontwikkelaars en de business en andere stakeholders. Gebruik die positie om deze ‘werelden’ samen te brengen. De user stories zullen er wel bij varen!

Arnoud Hoogeveen is Craft Expert van Team Testing binnen Craft, hét groeiprogramma voor IT'ers (powered by Centric).