Behaviour Driven Development (BDD)

Behavior Driven DevelopmentRegelmatig lees of hoor je dat IT-projecten falen, een langere doorlooptijd nodig hebben dan oorspronkelijk gepland en veel meer kosten dan oorspronkelijk gedacht. De oorzaken hiervoor zijn veelal te herleiden naar communicatieproblemen zoals:

  • de business is niet in staat om het gewenste gedrag eenduidig te benoemen
  • de ontwikkelaars begrijpen niet wat het gewenste gedrag is dat ze moeten ontwikkelen
  • de business begrijpt niet welke technische uitdagingen het gewenste gedrag met zich meebrengt

Wat is BDD?

Het primaire doel van BDD is om mensen te laten communiceren en de kloof te dichten tussen ‘technische’ en ‘business’ mensen. BDD zorgt voor communicatie tussen iemand met diepgaande technische kennis, iemand met een grondige business kennis en een professionele tester. Door deze verschillende stakeholders de functionaliteit te laten bespreken, de problemen te bespreken en te praten over hoe ze deze kunnen oplossen, zal leiden tot specificaties die door alle stakeholders op dezelfde wijze wordt begrepen.

Behaviour Driven Development (BDD) is een raamwerk voor  software ontwikkel activiteiten die teams helpt software te ontwikkelen:

  • die waardevol is,
  • die van hoge kwaliteit is
  • op een snellere manier

BDD maakt gebruik van Agile en Lean praktijken en in het bijzonder Test Driven Development (TDD) en Domain Driven Design (DDD). Het belangrijkste is dat BDD gebruik maakt van een gemeenschappelijke taal, gebaseerd op eenvoudige en gestructureerde zinnen.

BDD is ontwikkeld door Dan North. De ontwikkeling hiervan is begonnen in 2003 als reactie op problemen die Dan North ondervond met TDD.

Definitie:
Behaviour driven development is een manier voor het ontwikkelen van software, waarbij een applicatie wordt ontworpen door eerst het gedrag ervan te beschrijven. Het gedrag wordt beschreven vanuit het perspectief van alle betrokken stakeholders (business, ontwikkelaars, testers, etc.)

 

BDD is gebaseerd op de volgende 3 principes:

  • Genoeg is genoeg
    Er moet vooraf net genoeg analyse en ontwerp gedaan worden om te kunnen starten. Meer is verspilde moeite.
  • Lever waarde voor de stakeholder
    Er moet alleen gedaan worden wat waarde oplevert of het vermogen om waarde te leveren vergroot.
  • Alles draait om gedrag
    Op elk niveau kan dezelfde taal gebruikt worden om het gedrag van het systeem te beschrijven

Werkwijze

BDD richt zich op het duidelijk identificeren van het gewenste gedrag van een functie. Het gedrag wordt geïdentificeerd met behulp van het beschrijven van realistische voorbeelden, in plaats van te worden beschreven in abstracte en generieke jargon.

Het idee is om, samen met alle teamleden, vertegenwoordigers uit de business en mogelijk zelfs klanten, het gedrag van de software te definiëren. Dit kan middels een specificatie workshop. Deelnemers aan de specificatie workshop krijgen de opdracht om na te denken over hoe het systeem zich moet gedragen en beschrijven dat volgens een vast formaat.

De “The Three Amigos” is een goede manier om deze gesprekken te laten plaatsvinden. In essentie betekent “The Three Amigos” aanpak dat drie key stakeholders samen werken aan het uitwerken van een user story of feature voordat gestart wordt met de ontwikkeling van de software.

Veelal worden de volgende stakeholders hierbij ingezet:

  • business analyst of product owner
  • ontwikkelaar
  • tester

Een gemeenschappelijk taal helpt het hele team om te begrijpen wat er wordt verwacht van de functie. Hoewel het voor de verschillende teamleden van belang is om te kunnen werken met de nomenclatuur van hun eigen domein, is het van belang om te blijven realiseren wat echt belangrijk is: Wat de gebruiker ziet en doet.

Om dit te realiseren, gebruikt BDD Gherkin. Dit is  een eenvoudige taal, om te beschrijven hoe een functie zich zal moeten gedragen onder verschillende omstandigheden. De officiële standaard voor Gherkin wordt onderhouden door Cucumber, een van de belangrijkste BDD automatiserings frameworks.

In hoofdlijnen bestaat een Gherkin beschrijving uit een feature, in de vorm van een user story, requirements en voorbeelden in de vorm van scenario’s

Title (one line describing the story)

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

Requirements:

  • requirement 1
  • requirement 2

Scenario 1: Title

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

Scenario 2: …

  • In het artikel over Gherkin wordt in detail ingegaan op bovenstaande structuur en is een uitgewerkt voorbeeld opgenomen.

Voordelen BDD

  • Goede samenwerking
    BDD verhoogt en verbetert de samenwerking. Het stelt iedereen, die betrokken is bij het project, in staat zich gemakkelijk in te zetten voor de systeemontwikkeling. En door een eenvoudige taal te gebruiken, kunnen alle betrokkenen  scenario’s schrijven.
  • Gericht op toegevoegde waarde voor de business
    BDD hecht veel waarde aan de toegevoegde waarde voor de business. Door prioriteiten te stellen aan de business, op basis van de toegevoegde waarde die functionaliteit biedt, kunnen ontwikkelaars een beter resultaat leveren omdat ze een goed begrip hebben van hoe de business denkt. Door te focussen op de toegevoegde waarde, worden er geen nutteloze functies gebouwd.
  • Ubiquitous taalgebruik
    Ubiquitous taal is een idee uit Domain Driven Design om binnen een project een door iedereen gedeelde taal te gebruiken gebaseerd op het domein waarover het project gaat. Op deze manier worden misverstanden zoveel mogelijk vermeden en mensen van buiten het domein gedwongen deze gedeelde taal te leren.
  • Lagere kosten
    Door de kwaliteit van de code te verbeteren, verminderen de onderhoudskosten en worden de risico’s van het project geminimaliseerd.
  • Traceerbaarheid
    Alle ontwikkelde software is terug te traceren naar bedrijfsdoelstellingen.

Nadelen BDD

  • Vereist veel samenwerking / betrokkenheid
    In de basis gaat het bij BDD om communicatie. Wanneer er communicatieprobleem zijn tussen de verschillende stakeholders, zal BDD meer problemen opleveren dan dat het oplost.
  • Vereist iteratieve benadering
    BDD is niet geschikt voor een waterval aanpak. De business analist is niet meer de enige die de requirements van te voren schrijft, testers wachten niet meer met het registreren van bevindingen tot aan het einde van een release en ontwikkelaars overleggen regelmatig met de rest van het team.
  • Lijkt langzamer te gaan
    BDD vergt in het begin van een project veel tijd en moeite waardoor het kan lijken dat de ontwikkeling langzamer gaat dan anders.

A

Ook interessant?

Test first - X-driven development

Test first – Introductie tot X-driven development

TDD, BDD en ATDD zijn termen die regelmatig terugkomen in een Agile omgeving.  Ze zijn de afgelopen jaren steeds populairder ...
Meer Lezen
Story opzet voor BDD

Story opzet voor Behaviour Driven Development (BDD)

Behaviour Driven Development (BDD) gaat er van uit dat een idee voor een functie eenvoudig en effectief kan worden omgezet ...
Meer Lezen
Gerkin Syntax

Uitleg van de Gherkin Syntax

Binnen een Behaviour Driven Development (BDD) story vormen de scenario’s een belangrijk onderdeel. Elk scenario beschrijft een(1) enkel gedrag van ...
Meer Lezen
Tools voor Behaviour Driven Development (BDD)

Algemene introductie Tools voor BDD

Het primaire doel van BDD is om mensen te laten communiceren en de kloof te dichten tussen ‘technische’ en ‘business’ ...
Meer Lezen
Blijf op de hoogte van onze nieuwste ontwikkelingen, schrijf je hier in voor de nieuwsbrief!