Behaviour Driven Development (BDD) gaat er van uit dat een idee voor een functie eenvoudig en effectief kan worden omgezet naar geïmplementeerde, geteste en productie geschikte code, zolang de requirements specifiek genoeg zijn zodat iedereen weet wat er moet gebeuren. Om dit te realiseren, is er een manier nodig om de requirements zodanig te beschrijven dat iedereen – business, analist, ontwikkelaar en tester – een gemeenschappelijk begrip hebben van de scope en werking van de functionaliteit. Een BDD story kan trouwens ook gebruikt worden voor het beschrijven van niet-functionele requirements

Een story is een beschrijving van:

• een functie
• de toegevoegde waarde voor de business
• de requirements waaraan de functie moet voldoen
• scenario’s voor het beschrijven van voorbeelden

Structuur van een story

BDD biedt de onderstaande structuur voor een story. Deze structuur is niet verplicht, maar heeft zich in de praktijk wel bewezen. De story moet op zijn minst alle elementen bevatten die in de template worden beschreven.

Uitleg story aan de hand van een voorbeeld

Aan de hand van onderstaand voorbeeld wordt de opzet van een story uitgelegd.

De title beschrijft een activiteit

De title van een story moet een activiteit beschrijven. In bovenstaand voorbeeld is dat: “Webshop bezoeker ziet gerelateerde producten bij bekijken product”. Zolang deze functionaliteit nog niet is geïmplementeerd zal een webshop bezoeker dus geen gerelateerde producten zien. Zodra de functionaliteit is opgeleverd ziet hij ze wel. Dit is een mooi startpunt voor de “definition of done”.

De story moet een rol, functie en voordeel bevatten

Het gebruiken van onderstaand template heeft een aantal voordelen.

As a [role]
I want [feature]
So that [benefit]

Door de rol expliciet te specificeren, weet je met wie je moet praten over de functie. Door het voordeel te laten beschrijven, moet de schrijver nadenken over waarom een functie nodig is.

Requirements

De requirements beschrijven de eisen waaraan de functionaliteit moet voldoen en dienen als basis voor het uitwerken van de scenario’s

Title van scenario beschrijft het verschil

Wanneer de verschillende titles van scenario’s onder elkaar worden gezet moeten de titles het verschil tussen de scenario’s duidelijk maken.

Opbouw scenario

Ieder scenario moet worden beschreven met de Given-When-Then opzet.

Given [context]
And [some more context]…
When [event]
Then [outcome]
And [another outcome]…

Het gebruiken van given-when-then zorgt er in de praktijk voor dat de kans kleiner wordt dat beschrijvingen voor meerdere uitleg vatbaar zijn. Omdat alle key stakeholders betrokken zijn bij het uitwerken van de scenario’s ontstaat er een gemeenschappelijk begrip van de scope en werking van de functionaliteit.

Tot slot

Wanneer een BDD story is uitgewerkt kan gestart worden met het ontwikkelen van de code het eventueel automatiseren van de scenario’s voor de testuitvoering. De in een BDD story gebruikte given-when-then opzet is door Cucumber uitgewerkt naar de Gherkin taal. Gherkin kan gebruikt worden als basis voor het automatiseren van de testen. Cucumber is een van de bekendste BDD test automatiserings frameworks. De meeste andere BDD frameworks gebruiken ook Gherkin, maar zijn niet altijd 100% compatibel met de Gherkin standaard van Cucumber.