Follow Us on Twitter

Behaviour Driven Development de volgende stap in Scrum

September 2015 -Iedereen kent het wel: we zijn lekker bezig met Scrum, iedereen heeft zijn plek gevonden de rollen zijn verdeeld en iedereen werkt lekker binnen zijn rol. Wat vaak opvalt binnen een Scrum team is dat testers in het begin van een sprint hun testen voorbereiden, en aan het einde van de sprint voeren ze deze testen uit op basis van de story die door de ontwerper beschreven is. Tegelijkertijd gaan ontwikkelaars aan de slag met het ontwikkelen van deze specifieke story met als gevolg dat aan het einde van de sprint elke rol een ander beeld heeft van de werkelijke implementatie.

Het bovenstaande probleem is dat er op papier wel een team is, maar dat het team niet samenwerkt naar het gemeenschappelijke doel. Ze geven voordat de sprint begint punten aan de story’s en als eenmaal de sprint is gestart gaat iedereen zijn eigen weg.

Om de samenwerking tussen de verschillende rollen te versterken is er een methodiek geïntroduceerd: Behaviour Driven Development. Behaviour Driven Development is net als Test Driven Development een methodiek van ontwikkelen die helpt het bovenstaande probleem op te lossen.

Wat is Behaviour Driven Development?

Behaviour Driven Development is een manier van software ontwikkelen (die ontstaan is vanuit de gedachte van Test Driven Development), vanaf de wens tot aan de realisatie. Het begint met het schrijven van een story voor de sprint. In traditionele Scrum teams schrijft de ontwerper het grootste gedeelte van de story op basis van de gesprekken met de stakeholders. Deze story wordt vervolgens gedeeld met de rest van het team tijdens het schatten van de story’s. Dit gebeurt allemaal voor het starten van de sprint.

Bij Behaviour Driven Development heeft de ontwerper net als bij Scrum als enige contact met de stakeholders. Met de wensen van de stakeholders als basis, gaat de ontwerper samen met de ontwikkelaar en tester aan de slag. (Dit principe wordt binnen Behaviour Driven Development ook wel "The three amigos" genoemd). Samen bedenken ze scenario’s voor de wensen van de stakeholder: dit zijn zowel "happy path" als "fout" situaties. Deze scenario’s dienen als acceptatiecriteria voor de stakeholders en als basis van de geautomatiseerde acceptatietesten. Meer verdieping over dit proces later meer in dit Whitebook.

Behaviour Driven Development is ontstaan vanuit het perspectief van de ontwikkelaar. De ontwikkelaar wilde zijn automatische testen, die hij op basis van Test Driven Development ontwikkelde, leesbaarder maken voor de stakeholders. Hiermee wil de ontwikkelaar bereiken dat hij op basis van deze testomschrijvingen samen met de stakeholders kan bepalen wat hij moet programmeren en hij voorkomt dat hij functionaliteit vergeet of te veel programmeert. Deze ontwikkelaar was Dan North.

Waarom Behaviour Driven Development toepassen?

Behaviour Driven Development is nog niet zo bekend als Scrum of Test Driven Development. Het is ontstaan rond de tijd van Eric Evans’ boek "Domain Driven Design", waarin hij beschrijft hoe het domein model van het bedrijf centraal staat bij de ontwikkeling van software.

Op basis van deze gedachte hebben Chris Stevenson en Dan North de basis gelegd voor de manier hoe acceptatiecriteria geschreven kunnen worden, zodat deze ook geautomatiseerd kunnen worden. Vanuit de stakeholders komt er altijd een scenario als:

Als een ...( manager )
Wil ik ...( cijfers )
Zodat ik ...( mijn taak kan uitvoeren )

Vanuit deze manier van opschrijven van de scenario hebben Dan en Chris een korte variant gemaakt die goed te lezen is voor zowel de stakeholders alsook voor geautomatiseerde test tools. 

Given ...
When ...
Then ...

Op basis van het volgende voorbeeld wordt de relatie tussen de traditionele manier van scenario schrijven en de manier van Behaviour Driven Development duidelijker.

Traditioneel:

Als project manager wil ik een overzicht zijn van mijn medewerkers, zodat ik de productiviteit kan bepalen.

Vertaling in Behaviour Driven Development:

Given project manager
When alle medewerkers in een overzicht staan
Then wordt de productiviteit zichtbaar

Op basis van deze scenario’s en tevens acceptatietesten, gaat de ontwikkelaar met behulp van Test Driven Development aan de slag. De acceptatiecriteria worden verwerkt in wat kleinere integratie testen, totdat ze het niveau van Unit testen hebben. Van hieruit gaat de ontwikkelaar de echte functionaliteit binnen de applicatie ontwikkelen.

Deze manier van ontwikkelen zorgt ervoor dat de acceptatiecriteria afgestemd zijn met de stakeholders en direct geïmplementeerd zijn binnen de source code. Hiermee wordt voorkomen dat wensen van de stakeholder door doorontwikkeling kapot worden gemaakt. Doordat bij Behaviour Driven Development vanuit de acceptatiecriteria wordt geredeneerd, wordt de ruis die normaal kan ontstaan bij slecht omschreven unit testen voorkomen.

Acceptatiecriteria worden van tevoren opgezet met "The three amigos". Met de drie disciplines praten ze in een klein comité over de story. De tester legt uit hoe hij de applicatie gaat testen en bepaalt aan de hand van de story een aantal testcases. De ontwikkelaar legt uit waar in de applicatie hij de story gaat implementeren. De ontwerper brengt de juiste vertaling van de stakeholders wens. Al deze input wordt besproken en verwerkt in de story. Dit zorgt ervoor dat iedereen weet wat er van de story verwacht wordt. De tester weet dus dat de ontwikkelaar de software op basis van Behaviour Driven Development vanaf de unit testen tot aan de acceptatietest volledig geautomatiseerd getest heeft. Nu de tester minder tijd hoeft te besteden aan de acceptatietesten, krijgt hij meer ruimte om andere soorten testen uit te voeren, zoals exploratief testen of fuzz-testing. Dit zorgt ervoor dat de applicatie als geheel beter wordt getest.

Voorbeeld van een acceptatietest tot applicatie implementatie op basis van een voorbeeld uit hoofdstuk 10 van het boek BDD in Action door John Ferguson Smart.

High-level BDD acceptatietest:

Scenario: Nieuwe leden moeten starten als BRONS leden
Given Jan Jansen is geen Frequent Flyer lid
When zij registreert voor het Frequent Flyer programma
Then zij zal de status BRONS hebben.

Stap implementatie integratietest van de stap When met behulp van een reguliere expressie dat gelijk staat aan de "When" stap van de acceptatiestap de variabele "Jan Jansen" wordt via de "Given" stap meegegeven aan de "When" stap:

FrequentFlyer lid;
 
@When("^(h?:z?)ij registreert voor het Frequent Flyer programma$")
public void registreert_voor_het_Frequent_Flyer_programma() throws Throwable {
  lid = FrequentFlyer.metFrequentFlyerNummer("123456789")
            .genaamd(voornaam, achternaam);
}

Stap Low level Unit test voor het testen van één methode binnen een class.

public class WanneerRegistrerenNieuwFrequentFlyerLid {
 
  @Test
  public void moet_een_nieuw_lid_aan_kunnen_maken() {
    FrequentFlyer lid = FrequentFlyer.metFrequentFlyerNummer("123456789")
        .genaamd("Jan", "Jansen");
 
    assertThat(lid.getVoornaam()).isEqualTo("Jan");
    assertThat(lid.getAchternaam()).isEqualTo("Jansen");
    assertThat(lid.getFrequentFlyernummer()).isEqualTo("123456789");
  }
}

Stap implementatie van de applicatie code behorend bij de Unit test.

public static class FrequentFlyerBuilder() {
  private String frequentFlyernummer;
 
  public frequentFlyernummer(String frequentFlyernummer) {
    this.frequentFlyernummer = frequentFlyernummer;
  }
 
  public FrequentFlyer genaamd(String voornaam, String achternaam) {
    return new FrequentFlyer(frequentFlyernummer, voornaam, achternaam);
  }
}

Hoe Behaviour Driven Development toe te passen?

Nu de basisonderdelen van Behaviour Driven Development naar voren zijn gebracht gaan we kijken hoe we dit binnen een bestaand Scrum team kunnen toepassen. Hiervoor hoeft het team als samenstelling, en de manier van ontwikkelen niet te wijzigen. Er is nog steeds een Scrumboard en iedereen voert nog steeds taken uit.

Om niet meteen alle aspecten van Behaviour Driven Development toe te passen binnen het team is de introductie opgedeeld in twee stappen.

De eerste stap die gezet moet worden is de manier hoe story’s ready gemaakt worden. Zoals eerder genoemd zullen “The three amigos” in een kleine comité werken aan de story’s. Eén belangrijk punt hieruit is dat de scenario’s worden bedacht in de vorm die Dan en Chris hebben beschreven3. Tijdens het comité wordt besproken wat de impact van de wens is op de applicatie. Denk hierbij aan performance, complexiteit, werkbaarheid, en eventuele andere aanpassingen van bestaande functionaliteit. Ook wordt er gekeken hoe groot de story gaat worden op basis van een referentie story met een vergelijkbare aanpassing. Mocht dit in de ogen van de ontwerper groter of anders uitpakken dan dat de ontwerper in eerste instantie met de stakeholders had afgesproken, dan gaat de ontwerper, eventueel samen met de ontwikkelaar en tester, terug naar de stakeholders met een alternatieve story. Zo komen ze met z’n vieren tot een gewenste situatie.

De tweede stap bij het introduceren van Behaviour Driven Development binnen het Scrum team is de manier hoe er ontwikkeld wordt. Het is verstandig om bij deze stap niet direct met geautomatiseerde acceptatietesten te beginnen als de ontwikkelaars zelf nog niet zo bekend zijn met Test Driven Development of met het maken van geautomatiseerde testen in het algemeen. Het is beter eerst te beginnen met het opzetten van Unit testen die behoren bij een taak op het bord. Laat ze samen in de vorm van Pair Programming4 Unit testen schrijven, zodat ze kunnen discussiëren hoe een Unit test geschreven moet worden en waarvoor ze de test schrijven. Dit alles zorgt ervoor dat ze vertrouwd raken met het schrijven van een Unit test. De volgende stap is Test Driven Development waarbij de ontwikkelaar eerst de test schrijft en vandaaruit de functionaliteit. In deze fase kan de ontwikkelaar op basis van de acceptatiecriteria uit de story al wat testen bedenken. Wanneer het ontwikkelteam het schrijven van testen goed onder de knie heeft is het een kleine stap om de lagen, integratie en acceptatietesten, in omgekeerde volgorde te implementeren in het ontwikkelproces.

Conclusie

Wanneer er aan het einde van de sprint altijd testwerk overblijft en wanneer er tijdens de reflecties communicatie als verbeterpunt wordt aangemerkt of als je gewoon toe bent aan de volgende stap binnen je Scrum team is Behaviour Driven Development een echte aanrader. Met behulp van deze methodiek help je je team naar een hoger niveau op het gebied van communicatie en testen met als uitkomst software van hogere kwaliteit die dichter bij de eisen en wensen van de klant staat.

 

Referenties:

Waardering:
 
Tags:

Reacties

Inderdaad heel herkenbaar!

Het definieren van de user story met een ontwikkelaar en tester uit het team lijkt me inderdaad wel een goede manier om de user stories meer concreet te maken met duidelijker (SMART) requirements/acceptatie criteria.
Maar hier schuilt misschien ook een probleem. In scrum is niet bepaald welke ontwikkelaar een story binnen een sprint oppakt. Dat zou theoretisch niet mogen uitmaken, maar dat moet ik in de praktijk nog zien.

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.