ORDINA BLOGT

Behavior Driven Development

BDD - Behavior Driven Development, wat is het en welk voordeel zit er in BDD?

  • Sven van Laar
  • 16 december 2013

Behavior Driven Development (BDD)

Tijdens de Agile Testing Days van 2013 was 1 van de hottest topics Behavior Driven Development, in het kort BDD. Met name de keynote van Dan North (bedenker van BDD) was enorm inspirerend en motiverend. In deze blog post zal ik in het kort beschrijven hoe BDD is ontstaan, wat het is en de voordelen ervan.

Het ontstaan van BDD

BDD is ontwikkeld door Dan North, zijn artikel over BDD was als eerste gepubliceerd in 2006 in het Better Software magazine, als een reactie op Test Driven Development (TDD). De basis van BDD werd gevormd door een nieuwe visie op hoe we unit en acceptatie tests schrijven.

Over een periode van enkele jaren is Dan North samen met anderen tot BDD gekomen. BDD heeft als doel om de communicatie tussen developers, testers en niet-technische dan wel business deelnemers aan een software project te verbeteren.

Dan North gaf in 2009 tijdens de Testing eXchange de volgende beschrijving aan BDD:

“BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.”

Wat is BDD nu eigenlijk?

Dan North bedacht dat we tests moeten uitschrijven als volledige zinnen i.p.v. een methode in de testcode, waarbij elke zin start met een beschrijving van de business value. Deze acceptatie tests worden bechreven binnen het agile framework van een user story. De acceptatie criteria voor een user story worden beschreven in termen van scenario's. BDD is een effectieve maar ook een toegankelijke manier om zo in het gehele project dezelfde taal te spreken.

Het uitgangspunt is dat gedrag van functionaliteit makkelijker leesbaar is dan een klassiek testscript dat bestaat uit een serie van acties die de functionaliteit test. Een klassiek testscript kan een vals gevoel van veiligheid bieden, omdat ze niet het gedrag van het systeem beschrijven.

Voorbeeld van een klassiek testscript 

Logisch

Zoeken collega

Omschrijving

Fysieke stappen

Open pagina

Open url : [URL]

Invoer login

Vul in veld gebruikersnaam [gebruikersnaam]

Invoer password

Vul in veld wachtwoord [wachtwoord]

Login

Klik login button

Connect pagina wordt getoond

Controleer dat juiste pagina getoond wordt

Zoek collega

Vul een valide collega naam in bij Zoek mijn collega en klik op Zoek

Resultaat

Controleer dat collega is gevonden

 

Hoe ziet de relatie tussen een user story en een scenario eruit binnen BDD?

Voor een user story wordt het volgende format gebruikt:

Als een [specifieke user/ persoon / rol]

Wil ik [een gewilde feature/issue dat opgelost moet worden]

Zodat ik [voordeel van implementatie van feature]

Voor iedere user story worden vervolgens één of meer scenario’s opgesteld die uitgevoerd kunnen worden.

Acceptatie criteria/Scenario:

Gegeven [initiële context]

Wanneer [gebeurtenis/actie]

Dan [uitkomst]

Een voorbeeld hiervan zou kunnen zijn waarin je contactgegevens van collega’s kunt opzoeken:

User Story

Titel: Collega zoeken

Als een medewerker

Wil ik een collega zoeken

Zodat ik zijn contact details kan inzien

Een voorbeeld van een happy flow en een error path zouden dan volgens het gegeven-wanneer-dan template er zo uit kunnen zien (uiteraard zijn er meer dan deze scenario’s te bedenken) :

Scenario 1: Collega gevonden

Gegeven medewerker is ingelogd

Wanneer ik via Mijn collega’s een collega zoek op naam die bekend is

Dan toont het systeem de gevonden zoek resultaten

Scenario 2: Collega niet gevonden

Gegeven medewerker is ingelogd

Wanneer ik via Mijn collega’s een collega zoek op naam die niet bekend is

Dan toont het systeem dat er geen collega is gevonden

De test scenario’s worden als een levend document beschouwd. Door de tijd wijzigt het gedrag van het systeem. Test-scenario’s die niet meer van toepassing zijn worden weggehaald.

Scenario 1: Collega gevonden

Gegeven medewerker is ingelogd

Wanneer ik via Mijn collega’s een collega zoek op naam

Dan toont het systeem de gevonden zoek resultaten

En kan medewerker het profiel openen van de collega

Scenario 3: Collega profiel - CV

Gegeven een medewerker is ingelogd en heeft collega’s gevonden op naam

Wanneer de medewerker zijn collega profiel inziet

Dan kan de medewerker de CV van de collega inzien

Waar men voor moet waken is dat de tests geen complete verhalen (een veelvoud van gegeven, als en dan regels) worden, wat een anti-pattern genoemd wordt binnen BDD. Een verhaal kan wel worden gebruikt als user journey. User journeys zijn bedacht door Jez Humble om zo de reis van de gebruiker na te bootsen binnen het systeem. Echter deze “reizen” zijn langzaam in executie-tijd en dienen als pre-check voor de regressie. De user journey’s zijn er om te kijken of het systeem doet wat het moet doen vanuit een gebruikers perspectief. En niet zozeer als functionele regressie test.

Het bijkomend voordeel van scenario’s is dat het team samen met de stakeholders (subject matter expert/product owner, eind klant, andere project leden buiten het team) de tests kan reviewen en accepteren. Het accepteren van de tests door het team samen met de stakeholders heeft als voordeel dat het team de stakeholders mede verantwoordelijk maakt voor het testen. BDD is geen tool die je gebruikt. En omdat het geen tool is, kan het project of projecten dezelfde scenario’s gebruiken in elk platform (web/mobile/desktop). Puur omdat het gedrag beschrijft van het systeem. Omdat het gedrag beschrijft kunnen we de scenario’s gebruiken als communicatie- en  als testmiddel.

Omdat het scenario leesbaar is door alle betrokkenen kan men vrij snel detecteren of: er een bug geïntroduceerd is, het gedrag is verplaatst of het gedrag is niet meer relevant. Zoals eerder genoemd, een levend document in actie zodra een test faalt:

Bug geïntroduceerd? Fix bug.

Het gedrag is verplaatst? Verplaats test en wijzig waar nodig.

Gedrag niet meer relevant? Verwijder test.

 Er zijn tegenwoordig veel frameworks voor geautomatiseerd testen die BDD ondersteunen, zoals Cucumber, RSpec, Specflow en jBehave.  Mocht je een van deze frameworks willen uitproberen zijn er genoeg tutorials te vinden via google om te starten met het framework naar keuze.

Tot slot

Ik ben ondertussen een enorme fan van BDD geworden en ik zie er veel voordelen in. Vooral omdat het een communicatie middel is dat door het gehele project kan worden gebruikt. Daarbij kan je heel makkelijk de rest van het project mede verantwoordelijk maken voor de tests, want binnen Agile draait het om samenwerken en samen een product te leveren waar de klant iets aan heeft.

Binnen mijn project bij de Rabobank zijn wij nu al een geruime tijd bezig met BDD en het heeft ons veel voordelen opgeleverd. Voordelen die wij nu hebben zijn.

Door behavior driven development met de subject matter experts te doen (product owner, business analisten), zijn we in staat om tests te beschrijven die iedereen begrijpt voordat er code wordt gemaakt. Daarbij helpt het bij de 3 amigo’s principe; de developer, tester en SME (subject matter expert) komen bij elkaar. De SME heeft voor de meeting de requirements opgesteld. De requirements worden aan de hand van voorbeelden besproken (specification by example), zodat iedereen exact snapt wat er moet gebeuren. Vervolgens is de test specialist in staat om dan al test scenario’s te definiëren. Niet alle mogelijke test scenario’s hoeven dan al beschreven te worden, maar wel wat datgene wat ons genoeg vertrouwen geeft (want testen is immers vertrouwen creëren)  om de requirement tijdens development constant te valideren. De 3 amigo meeting kan ook meer dan 3 personen bevatten als dat nodig is, de meeting is bedoeld om te kijken wat gaan we testen maar ook hoe gaan we testen. Het voordeel van deze werkwijze is dat de developer al geteste code oplevert. Die geteste code hoeft dan alleen nog exploratory getest te worden, wat de feedback loop verkort en development time verkort.

De tests zijn beter leesbaar en beschrijven alleen gedrag wat customer value heeft. Daarbij zijn de scenario’s uitvoerbaar als tests en dienen als levende documentatie binnen het project. Er is meer focus op wat we nu eigenlijk testen.