Follow Us on Twitter

De valkuilen van Behaviour Driven Development

Februari 2016 - In Agile omgevingen wordt vaak Test Driven Development (TDD) toegepast. TDD is een methode van software ontwikkelen, waarbij de test eerst geschreven wordt en daarna gevolgd wordt door het schrijven van de code. TDD is ontstaan als onderdeel van extreme programming in 1999. De focus hiervan ligt vaak op de broncode en het ontwerp van de applicatie.

Behaviour Driven Development (BDD) gaat uit van hetzelfde idee, waarbij er van buiten (test) naar binnen (code) wordt gewerkt. Alleen nu gaan we uit van een falende acceptatietest die het gedrag van het systeem beschrijft. Deze test beschrijft het systeem vanuit het oogpunt van de klant of eindgebruiker. We schrijven deze tests als voorbeelden van het gebruik van het systeem. Deze voorbeelden gebruiken we om nog voor aanvang feedback te krijgen van de stakeholders.

In het Whitebook behaviour driven development de volgende stap in scrum wordt een grondige introductie gegeven.

In dit Whitebook wil ik verder ingaan op de valkuilen bij het invoeren ervan en hoe het een goede plaats kan krijgen binnen de gehele teststrategie.

Behaviour Driven Development

In BDD zijn de acceptatietests het startpunt voor het ontwerp van de software en dienen als basis voor communicatie tussen het team en de stakeholders. De tests worden geschreven in een natuurlijke taal om er zeker van te zijn dat het leidt tot een gedeeld begrip over de gewenste functionaliteit. Een van de grootste uitdagingen in softwareprojecten is dat iedereen in zijn eigen taal spreekt. De domeinspecialisten beschrijven het systeem met hun eigen jargon, terwijl technische teamleden hun eigen taal gebruiken om het domein te bespreken vanuit het oogpunt van het ontwerp. Op de grens van deze twee talen proberen de stakeholders duidelijk te maken wat de wens is.

Juist op dit grensvlak waar verschillende talen bij elkaar komen en het lastig is om elkaar te begrijpen, ontstaan de meeste misvattingen. BDD biedt een manier om requirements vast te leggen zodat iedereen begrijpt wat de scope en de acceptatiecriteria zijn. Het geeft een raamwerk om de acceptatiecriteria van een nieuwe functie vast te leggen. Als alle acceptatiecriteria worden ingevuld dan werkt het naar behoren; zo niet, dan werkt het niet naar behoren. De kracht van BDD is dat de acceptatietests door iedereen in het team gelezen en geschreven kunnen worden. Hier ligt dan ook de echte kracht van BDD, als communicatiemiddel en als stuwende kracht achter een betere samenwerking. De tests worden geautomatiseerd door de code van een ontwikkelaar, maar worden begrepen door de business stakeholder. Voor een verdere uitleg over de opmaak van de testscenario’s verwijs ik opnieuw naar het Whitebook: behaviour driven development de volgende stap in scrum.

Check out what Dilbert has to say about end users and software design: 

Dilbert

Randvoorwaarde

De business stakeholders moeten vanaf de start actief betrokken zijn. Dit is de belangrijkste randvoorwaarde die geborgd moet zijn. BDD is niet een hulpmiddel voor testautomatisering, maar een manier om business requirements vast te leggen. Ze moeten geschreven worden voordat de productiecode wordt geschreven. Het bepalen van de requirements begint bij de business stakeholder of de business analist. De communicatie over de functionaliteit moet altijd centraal blijven staan.

Het is belangrijk om bij de introductie van BDD niet de focus te leggen op de tool en de mogelijkheden om tests te automatiseren. Testen heeft vaak een negatieve bijklank. Het gaat om het specificeren van functionaliteit en niet om het testen van functionaliteit.

Leg niet de volledige verantwoordelijkheid van het vastleggen van de scenario’s bij de klant. Het moet een gedeelde inspanning zijn, uiteindelijk moet het team de wensen begrijpen. De klant moet voldoende informatie verstrekken over het probleem dat opgelost moet worden, zodat ze gezamenlijk concrete scenario’s kunnen opzetten die gebruikt worden tijdens het ontwikkelproces.

Het heeft geen enkele zin om met BDD te starten als deze randvoorwaarde niet is ingevuld.

Valkuilen

Ik zal in deze paragraaf een aantal valkuilen bespreken die je kunt tegenkomen bij BDD en wat er tegen gedaan kan worden.

Teveel scenario’s

Vaak proberen we zo volledig mogelijk om acceptatiecriteria te beschrijven met scenario’s. Als de scenario’s te complex worden of de volume van de scenario’s te groot dan zal het zijn gewenste effect missen. Het zal niet snel uitnodigen tot discussie. Het aantal scenario’s geeft een vals gevoel van volledigheid. Ook al kan elk individueel scenario eenvoudig te begrijpen zijn, pagina’s achtereen van scenario’s zorgen ervoor dat je letterlijk door de bomen het bos niet meer kan zien. Het belangrijkste is dat bij te complexe scenario’s of teveel scenario’s het verfijnen van de User Story nog niet klaar is. Zie dit Whitebook voor meer informatie over succesvol Product Backlog onderhoud. Probeer dit te voorkomen door te focussen op de belangrijkste scenario’s.

Tips:

  • Zoek naar ontbrekende concepten;
    Gebruik deze nieuwe concepten binnen de functie om de specificatie onder te verdelen in duidelijke eenheden.
  • Groepeer gelijke scenario’s en kies een beperkt aantal variaties;
    Focus op de belangrijkste variaties en kies hiervoor, probeer je zoveel mogelijk te beperken tot de meest veelzeggende voorbeelden.
  • Maak een scheiding tussen validatie en verwerking in de scenario’s.
    Door een expliciete scheiding op te nemen tussen validatie en verwerking kan een grote groep complexe voorbeelden verdeeld worden in twee groepen.

Het runnen van de volledige testset duurt te lang

Het hebben van veel features en bijbehorende scenario’s is een van de belangrijkste redenen om ervoor te zorgen dat de run te lang duurt. Behalve dat het lang duurt voordat je feedback hebt, is een te grote testset moeilijk om te onderhouden en georganiseerd te houden.

Tips

  • Verwijder alle tijd gerelateerde wachtstanden in je tests.
    De tijd die nodig is voordat een event optreedt, verschilt enorm per omgeving. Als je de wachttijd te laag zet dan zullen veel tests falen vanwege verschillende wachttijden per omgeving. Aan de andere kant als je de wachttijd te hoog zet gaat daarmee de algehele doorlooptijd steeds verder omhoog. Wacht op het optreden van het event, in plaats van het wachten gebaseerd op tijd.
  • Maak slim gebruik van hooks om een uitgangssituatie te creëren voor meerdere scenario’s.
    Veel scenario’s hebben een gedeelde context die in ieder scenario voorbereid wordt. Een uitgangssituatie waar meerdere tests op voortborduren. Met behulp van hooks is het mogelijk om de uitgangssituatie 1 keer voor te bereiden. Na deze voorbereiding kunnen alle tests vanaf dat punt verder runnen.
  • Maak gebruik van tags om groepen scenario’s te onderkennen;
    In de meest bekende BDD frameworks (zoals bijvoorbeeld Cucumber) kunnen tags worden toegepast om verschillende groepen te onderkennen. In Cucumber ziet een tag er als volgt uit:

    @tagname

    Vervolgens kunnen op basis van deze tags testgroepen parallel worden getest of specifieke testgroepen worden uitgesloten. Kijk op de tags pagina van Cucumber voor meer informatie over hoe dit toegepast kan worden. Er zijn diverse plugins beschikbaar om testgroepen parallel te draaien, zoals de cucumber-jvm-parallel-plugin.\

De tests zijn moeilijk te lezen

Vaak raken de feature files onoverzichtelijk doordat de verschillende scenario’s te veel steps kennen.
Hieronder wordt een voorbeeld gegeven van een scenario waarbij de klant een Smurf koopt. 

Voorbeeld 1:

Background:
Given the user is on "Search page"
When the user enters "Smurf" into "Search text box"
And the user clicks "Search"
Scenario: Customer buys a Smurf
When I select Smurf  
And I press "Add to basket"
And I press "Checkout"
And I enter "Lorem Ipsum" into the "Name field"
And I enter "Dolor Sit 123" into the "Address field"
And I enter "lorem.upsum@dolor.sit" into the "Email field"
And I select "Credit card" from the "Pay with dropdown"
And I click the "Place order button"
Then I should see "Thank you for your order".

Voorbeeld 2, afkomstig van Liz Keogh, laat zien waar de business stakeholder eigenlijk op wil voortborduren:

When the Customer buys a Smurf 

Tips:

  • Schrijf de scenario’s op een declaratieve wijze;
    Bij het schrijven van scenario’s onderscheiden we een imperatieve stijl van een declaratieve stijl. 
  • Pas Given – When – Then op een strikte wijze toe;
    Gebruik na Given verleden tijd, na When tegenwoordige tijd en na Then toekomstige tijd. Daarmee wordt het duidelijk dat Given een preconditie of een parameter beschrijft en Then een postconditie of een verwachting. Schrijf Given en Then passief en When actief omdat dat een actie beschrijft. Op deze manier worden de scenario’s duidelijker leesbaar en blijven ze herkenbaar qua stijl. 
  • Geef bij ieder scenario een duidelijke context;
    Door bij het schrijven van een scenario van tevoren voldoende context te geven is het scenario in de toekomst ook nog duidelijk te lezen. Zorg ervoor dat het scenario duidelijk is op basis van de gegeven context voor iemand buiten het team, maar met voldoende domeinkennis.
  • Hou de taal die gebruikt worden in de scenario’s gelijk;
    Door de taal consistent te gebruiken gedurende het ontwikkelproces wordt het makkelijker om de scenario’s te lezen en te begrijpen.

In Imperative vs Declarative Scenarios in User Stories beschrijft Ben Mabey het verschil tussen imperatief en declaratief:

  • Imperatief 
    In de imperatieve stijl gebruiken we granulaire steps waarbij we vaak refereren aan elementen uit de GUI. Het toevoegen van een nieuw veld kan dan ook leiden tot een aanpassing van het scenario, ook al blijft het onderliggende doel gelijk. Zo is ook terug te zien in Voorbeeld 1 hierboven.
  • Declaratief 
    Bij de declaratieve stijl blijft het doel van het scenario duidelijker. De scenario’s bevatten een stuk minder steps dan in de imperatieve stijl. De complexiteit is belegd binnen de uitwerking van de steps. Als er velden bijkomen dan vertaalt zich dat naar een aanpassing in de step definities, maar het scenario blijft gelijk. Voorbeeld 2 is een declaratief scenario. 

Conclusie

In het dagelijks leven helpen voorbeelden bij de communicatie. Ze helpen bij het begrijpen van het onderwerp en maken het levendig. De meest beperkte vorm van BDD is een gesprek hebben over de scenario’s, de scenario’s niet vastleggen en niet automatiseren. Dat is ook de kern van BDD. Vergeet niet dat als de gesprekken niet plaatsvinden, je geen BDD doet. Er zijn zoals ook in dit Whitebook geschetst diverse valkuilen bij het toepassen van BDD. Het belangrijkste om in de gaten te houden is dat de feedback loop vooral snel moet zijn. Een ontwikkelaar moet na wijzigingen in de code vrijwel direct kunnen weten of daarmee fouten zijn geïntroduceerd. Omdat BDD erg krachtig kan zijn als hulpmiddel om nieuwe functionaliteit te specificeren of ontwerpen kunnen het aantal scenario’s enorm toenemen. Wees hier van meet af aan scherp op en beperk je zoveel mogelijk tot de meest essentiële scenario’s.

Waardering:
 
Tags:

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.