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.