Agile, Trendsz, Test engineering, Testautomatisering

Behaviour Driven Development (BDD) is ontstaan om heldere communicatie tussen developers, testers en niet-technische deelnemers mogelijk te maken om zo samen betere software te kunnen ontwikkelen. Maar wat is BDD eigenlijk? Waarom zou je het verkiezen boven Test Driven Development (TDD)? Welke rol spelen voorbeelden, scenario’s en rapportages bij BDD? En niet te vergeten; wat betekent BDD voor de rol van de tester? Ik sprak erover tijdens onze Bijtanken Bij Bartosz sessie. Heb je dat gemist? In dit artikel stip ik de belangrijkste aspecten van BDD aan om daar in volgende artikelen dieper op in te gaan.

Wat is Behaviour Driven Development?

Eén vab de kenmerken van BDD is dat je voorbeelden gebruikt om het gewenste gedrag van de te ontwikkelen software te beschrijven. Deze voorbeelden zijn voor iedereen leesbaar en begrijpelijk; voor business, IT en alle andere betrokkenen. Binnen BDD speelt de vraag waarom de betreffende feature ontwikkeld moet worden een grote rol. Daarnaast is het een methode die ervoor zorgt dat alle betrokkenen elkaar kunnen begrijpen. BDD kun je zien als een voorschrijvende werkwijze op het gebied van structuur en proces, waarmee ontwikkelteams kunnen werken.

Waarom Behaviour Driven Development?

BDD is ontwikkeld om de communicatie tussen developers, testers en niet-technische deelnemers aan een softwareproject te verbeteren. Het komt voort uit het Test Driven Development (TDD). Bij TDD schrijft de ontwikkelaar eerst zijn unit test voordat er ontwikkeld wordt. Dit dwingt hem om onder andere na te denken over het ontwerp van zijn applicatie. Maar waar de ontwikkelaar bij het werken volgens TDD niet over na hoeft te denken is waarom de code wordt beschreven. Ofwel; waarom hij maakt wat hij maakt. Waarom wil de klant deze software? Wat is de vraag achter de klantvraag? En is de bedachte oplossing een antwoord daarop? Deze aspecten blijven binnen TDD onbelicht. BDD legt door te werken met leesbare en begrijpelijke voorbeelden wel de link tussen het technische niveau (het ontwikkelwerk) en het functionele niveau (de klantwens). Wanneer het team weet waarom de klant een bepaalde feature gerealiseerd wilt zien is het ook mogelijk alternatieve (technische) oplossingen voor te stellen. Op deze wijze wordt de mogelijkheid gecreëerd voor team en klant om elkaar uit te dagen de beste oplossing (in termen van geld, time-to-market en kwaliteit) te realiseren.

Testers zijn binnen BDD onmisbaar in het ontwikkel-proces en het helder krijgen van de business wens.

Hoe zet je Behaviour Driven Development op de juiste manier in?

Om technische en niet-technische projectleden dezelfde taal te laten spreken bij het vaststellen van het gewenste gedrag van de te ontwikkelen software, werk je binnen BDD met toepasbare voorbeelden: oftewel Specification By Example. In deze voorbeelden gebruik je gedrag om de werking van een applicatie te omschrijven. Om het proces om gezamenlijk met elkaar in gesprek te gaan over het gewenste gedrag te stroomlijnen, werken we binnen BDD met The Three Amigos sessie. Deze sessie is vergelijkbaar met de ‘Refinement’ sessies uit Scrum en heeft als belangrijkste vereiste dat de drie rollen – business, ontwikkelaar en QA – aanwezig zijn.

Waarom zijn voorbeelden zo belangrijk bij Behaviour Driven Development?

Het gebruik van leesbare en begrijpelijke voorbeelden speelt binnen BDD een belangrijke rol omdat het een helder beschreven user story oplevert die voor iedereen te lezen en te volgen is. Dat creëert een shared understanding met als voordeel dat er vrijwel geen handovers zijn in documentatie en er daardoor minder ruis is in de communicatie over wat er van een user story wordt verwacht. In principe zijn een duidelijke titel, een korte en krachtige omschrijving van het ‘waarom’ en ‘wat’, aangevuld met een aantal goede voorbeelden, een uitstekend uitgangspunt om met elkaar in gesprek te gaan. Met behulp van een heldere user story is bovendien makkelijker te ontdekken of er nog vragen aanwezig zijn, waar de business duidelijkheid over moet verschaffen. In mijn artikel ‘Het gebruik van voorbeelden binnen BDD’ ga ik hier verder op in. Hier alvast een aantal aandachtspunten:

  • Begin altijd met het benoemen van een aantal happy-flow voorbeelden. Dit creëert namelijk een structuur die in een tabel is te verwerken.
  • Ga op basis van je happy-flow voorbeelden op zoek naar de grensgevallen.
  • Introduceer ieder grensgeval door de vraag in te leiden met: ‘Wat als…’.
  • Eindig je met een heleboel voorbeelden? Zorg dan dat je de relevante voorbeelden overhoudt.
  • Blijf je alsnog met te veel voorbeelden zitten? Vraag jezelf dan af of de user story niet te complex is.

Hoe gebruik je scenario’s binnen Behaviour Driven Development?

Op basis van de vastgelegde voorbeelden bepaal je het aantal scenario’s dat nodig is om het functioneren van de applicatie voor business en IT duidelijk te maken. Ook deze scenario’s schrijf je in de domeintaal van de business. De voorbeelden worden omgezet in een Given-When-Then stramien, ook wel Gherkin syntax genoemd. De ontwikkelaar kan deze Given-When-Then scenario’s gebaseerd op de voorbeelden gebruiken om zelf te testen of zijn werk voldoet. Deze test-driven aanpak wordt nog krachtiger als de scenario’s voorafgaand aan het ontwikkelen worden geautomatiseerd met behulp van BDD test automatiseringstools.

"Werken met BDD-voorbeelden is een enorm waardevolle toevoeging voor Agile teams die werken binnen complexe domeinen"

Welke rol speelt rapportage bij Behaviour Driven Development?

Rapportage binnen BDD speelt een belangrijke rol. Omdat een goede testrapportage direct feedback geeft aan de ontwikkelaar. Daarnaast kun je het ook gebruiken om andere betrokkenen te informeren over de voortgang. Gebruik daarvoor een web-dashboard. Zet dit op binnen een build & deploy proces zodat ook dit voor iedereen automatisch toegankelijk is. De testrapportage wordt continu aangevuld met nieuwe scenario’s afkomstig uit de user stories en is daarmee een vorm van Living Documentation die het functioneren en de kwaliteit van de applicatie aangeeft. Omdat het ontwikkelteam en de business deze Living Documentation als een single point of truth kunnen beschouwen, hoeven zij niet ook nog op andere plekken documentatie bij te houden.

Welke rol heeft de tester binnen Behaviour Driven Development?

Zoals eerder aangegeven kunnen ontwikkelaars binnen BDD met behulp van de Given-When-Then scenario’s prima hun eigen werk toetsen. Dit werk heeft echter meestal een beperkte test scope aangezien er later altijd nog nieuwe voorbeelden kunnen worden gevonden die niet in een scenario worden afgedekt. Bovendien zijn nieuw gebouwde functionaliteiten vaak onderdeel van een grotere geheel van de applicatie. Het is binnen BDD dan ook de taak van de tester om met behulp van exploritory tests op zoek te gaan naar mogelijke gemiste voorbeeldsituaties. Maar dat is niet zijn belangrijkste taak binnen BDD: omdat testers sterk zijn in het concretiseren van voorbeelden, zijn zij binnen BDD onmisbaar in het ontwikkelproces en het helder krijgen van de business wens, bijvoorbeeld door hun aanwezigheid tijdens The Three Amigos sessie.

Is werken volgens Behaviour Driven Development iets voor jou?

Bedenk voordat je voor werken volgens BDD kiest eerst welk probleem je ermee wilt oplossen. Een testautomatiseringsprobleem kun je immers ook met andere tools oplossen. Teams die een zeer hoge mate van Agile volwassenheid hebben en die succesvol zijn in het continu verbeteren van hun product, kunnen bovendien juist hinder ondervinden van werken volgens BDD. Omdat BDD erg voorschrijvend is in aanpak en daarnaast op den duur een overdaad aan documentatie oplevert waar niemand meer naar kijkt. Echter, de kern van BDD – werken met voorbeelden volgens Specification By Example – blijft het meest interessant en relevant aan de werkwijze. Omdat dit een enorm waardevolle toevoeging is voor teams die werken binnen complexe domeinen.

Wil je ons nieuwste Paarsz magazine per post ontvangen? Laat dan je gegevens achter.

Ontwerp zonder titel (19)

Werken bij Bartosz?

Vincent Verhelst

Geïnteresseerd in Bartosz? Dan ga ik graag met jou in gesprek. We kunnen elkaar ontmoeten met een kop koffie bij ons op kantoor. Of tijdens ontbijt, lunch, borrel of diner op een plek die jou het beste uitkomt. Jij mag het zeggen.

Mijn Paarsz