ATDD / BDD: wat heb ik eraan?

Redactie: Gerben de la Rambelje
Auteur: Pascal Dufour  ● pascal@validate-it.nl

Op de thema-avond ‘Agile/Scrum’ van afgelopen 14 januari was er de kans om als tester te ervaren wat ATDD / BDD is. Aan aandacht geen gebrek, het was een volle bak, de deur ging dicht en meer mensen mochten er niet meer in.
Zowel Acceptance Test-Driven Development (ATDD) als Behaviour Driven Development (BDD) aanpakken komen erop neer dat ze betere communicatie tot stand laten komen tussen de behoefte van de business en het developmentteam. Deze communicatie wordt vaak concreet gemaakt in specificatie. Als testers weten we hoe moeilijk het is om een goede (test)specificaties te schrijven. We willen dus specificaties gaan opschrijven en deze automatiseren.
 
Wat is ATDD / BDD eigenlijk?:

• Het is dus een kwestie van specificaties op een bepaalde manier opschrijven?
• Het gaat om het automatiseren van specificatie (testen)?
• Niets van bovenstaande!

 
Waar gaat in ATDD / BDD dan wel om?
Waar gaan deze aanpakken dan wel over en waar komen ze vandaan? Het zijn aanpakken die gaan over ‘bridging the communication gap’, zoals Goiko Adzic het mooi beschrijft. Het gaat erom dat het developmentteam en de business elkaar goed begrijpen en een gezamenlijk beeld hebben van de problematiek. Om het gezamenlijk beeld concreet te maken schrijven we het samen op in de taal van de business. Het gaat bij de business om wat de gebruiker kan en niet om wat voor technische oplossingen er ontwikkeld gaan worden. Het gaat dus om het gezamenlijk beeld van het product dat er ontwikkeld moet worden
 
Herkomst ATDD / BDD
Waar komt deze aanpak vandaan? Eén van de oorsprongen is te vinden in de begintijd van de Test-Driven Development (TDD), waar ze (onder andere Kent Beck) een unit-testje schreef om te kijken of de code wel deed wat ze ervan verwachten. Later hebben ze de werkwijze omgedraaid (eerst de test dan de code). Kent Beck heeft dit verder ontwikkeld in eXtreme Programming (XP), naar automatische acceptatie testen (Story testing) in de taal van de business. Deze testen hebben veel meerwaarde bij wijzigingen van de code, zodat ze nog steeds voldoen aan de verwachtingen.
 
Werking ATDD / BDD
Het gezamenlijk beeld ontstaat door samen met de business in discussie te gaan over de functie die gebouwd moet gaan worden. Een sessie waar deze verduidelijking plaatsvindt, wordt ook wel de ‘requirement workshop’ genoemd.
 
De doelstelling van een ‘requirement workshop’ is het creëren en het helder krijgen van de user stories voor het gehele team. Discussie moet gaan over het waarom we deze user stories moeten maken, welk probleem zullen de stories gaan oplossen. Welke acceptatietesten zijn nodig voor het ontwikkelen en valideren van de user story.
 
De doelstelling voor een ‘requirement workshop’ kan onder andere zijn:

• We willen 2 à 3 voorbeelden van acceptatietesten hebben van elke user story;
• We willen voor elke user story een exploratory test charter.

 
Een ‘requirement workshop’ duurt één tot twee uur. Het probleem dat eerst aandacht behoeft, is het zeer goed begrijpen van de user story vanuit een bepaalde persona (denk aan: de operation engineer, de key user, de nieuweling, et cetera). We moeten weten waarom deze persona deze behoefte heeft en welk probleem hij opgelost wil zien. Dit is een requirement probleem. De te beantwoorden vraag is: ‘Welk probleem heeft de klant en waarom wil de klant het opgelost hebben?’.
 
Een user story is ook een requirement waarvoor een oplossing ontworpen moet worden. Daarom moet de volgende vraag beantwoord worden: ‘Welke oplossing past het beste bij de wensen van de klant?’. De details van het ontwerp worden niet beantwoord in de ‘requirement workshop’, maar er wordt wel over nagedacht.
 
Uiteindelijk hebben we nog het ‘test probleem’. De vragen die hiervoor beantwoord moeten worden zijn:

• Hoe weten we dat de oplossing het probleem van de gebruiker oplost?
• Levert de nieuwe oplossing meer waarde dan de vorige oplossing?
• Hoe weten we dat we het juiste probleem hebben opgelost?
• Is het probleem dat we hebben opgelost ook het probleem dat de klant wil dat we oplossen?
• Hoe weten we dat we het probleem juist hebben opgelost?
• Hoe kwantificeren we het succes en de fout van de oplossing?

 
We zouden hier ‘testen’ kunnen inzetten om antwoord op deze vragen te vinden en te beantwoorden.

 
Hoe faciliteer je een requirement workshop?
Er is een aantal zaken waar je rekening mee moet houden om succesvol een ‘requirement workshop’ te faciliteren. Allereerst is het belangrijk om een doel te stellen aan het begin van de workshop om betrokkenheid te krijgen. Vervolgens bediscussieer je de stappen die je wilt nemen. De agenda wordt bepaald om vervolgens vast te stellen wat gaan we doen en wanneer hebben we het doel bereikt. Nadat dit duidelijk is, spreken we de regels af van de ‘requirement workshop’:

• Hoe gaan we om met verstoringen zoals overgaande telefoons?
• Het interrumperen van elkaar wanneer we aan het woord zijn?
• Mogen we een e-mail lezen tijdens de workshop?

 
Mocht het zijn dat je al vaker een ‘requirement workshop’ met het team hebt gedaan, herinner dan het team even aan de afgesproken regels en toets of ze hier nog altijd achter staan.
 
Om creativiteit een boost te geven maken we gebruik van time boxing. Geef ook tijdig aan dat de tijd is verstreken voor een onderwerp. Bijvoorbeeld elke 10 tot 15 minuten geef je aan hoeveel van de tijd is verstreken, of er nog genoeg tijd over is en check of er nog gewerkt wordt aan het belangrijkste punt. Het gebruiken van een parking lot, een plek waar vragen geparkeerd kunnen worden, zodat we kunnen blijven focussen op ons doel. Als je vragen krijgt die niet relevant zijn of te veel tijd consumeren, dan zet je ze op de parking lot en behandel je ze aan de einde van de meeting nog kort.
 
Een stappenplan voor een succesvolle requirement workshop
In de ‘requirement workshop’ voor het vaststellen van de testcases wil je de volgende stappen volgen:

• Introductie: Leg uit wat het doel en de agenda is van de ‘requirement workshop’.
• Begrijpen van de business value: De Product owner legt een coherente set van user stories uit met een doel (Sprint doel als je Scrum gebruikt) en relateert ze aan de business doelstellingen. Het team bediscussieert ‘waarom doen we dit?’. In onze workshops gebruiken we impact maps en de 5 Why’s.
• Begrijpen van de klantwaarde: Het team splitst zich op in teams en verdeelt de user stories. De subteams creëren scenario’s van de huidige situatie van de persona’s, zodat ze de situaties goed begrijpen waar de uitdagingen liggen. Tevens creëren ze scenario’s van de situatie zoals die zal zijn als het probleem is opgelost. Op deze manier begrijp je beter wat de voordelen zijn van de oplossing. Het team komt vervolgens weer bij elkaar en bediscussieert de gecreëerde scenario’s met gehele team. Het team bediscussieert ‘Waarom wil de persona dit?’ We doen dit door middel van een StoryBoard en Pain Gain map.
• Destilleren van de acceptatietesten: Het team creëert de acceptatietesten voor de user stories. Afhankelijk van de tools die je gebruikt zijn het Gherkin specificaties (Given, When, Then) flow tables of decisions tables. Het team wordt gesplitst in subteams en gaat aan de slag met de tabellen of de Gherkins specificatie in samenwerking met de Product owner. Dit alles doen we op whiteboards, zodat het voor elk teamlid goed te volgen is (gezamenlijk begrip).
• Definiëren van exploratory test charters: Identificeer risico’s om de exploratory test charters een doel te geven. Nu het duidelijk is welke risico’s we willen mitigeren, kunnen we manuele testen bedenken door als team exploratory test charters te definiëren. We doen risicoanalyse door bijvoorbeeld een impact matrix op te zetten. Verder kunnen we exploratory testing tours gebruiken om de charters te maken.
• Afsluiting: een korte samenvatting opstellen en de laatste opmerkingen toevoegen.

 
Het bovenstaande stappenplan zou je kunnen gebruiken voor jouw ‘requirement workshop’.
 
Tijdens de thema-avond hebben we de kracht ervaren van het discussiëren en creëren van voorbeelden om een gezamenlijk beeld te krijgen. Dit zijn de eerste stappen binnen de ‘requirement workshop’. Het lijkt namelijk erg eenvoudig, maar dat is het zeker niet.
 
We hebben nu een beschrijving van een user story inclusief een aantal voorbeelden van acceptatietesten. Deze voorbeelden zijn in co-creatie gecreëerd door het gehele team. Kijkend naar ATDD en BDD worden er vaak tools gebruikt, zoals Cucumber en Fitnesse. Kan ik de specificatie één op één in één van de tools plakken.
 
Ja, dat is juist de bedoeling.
 
In het volgende deel gaat over hoe het een ‘Levende’ specificatie wordt. Hoe embed je het in de development pipeline.
 
Pascal Dufour