Centraal in de wereld van softwareontwikkeling staat de behoefte aan duidelijke communicatie en gedeeld begrip. Dit is echter vaak een uitdaging, vooral bij complexe projecten met meerdere belanghebbenden en talloze functionaliteiten.
Neem deze leuke cartoon als voorbeeld. Het geeft perfect weer hoe de communicatie in de meeste projecten verloopt. In de wereld van softwareontwikkeling komt het maar al te vaak voor dat een klant een schommel wil, maar een stoel krijgt en een rekening krijgt voor een achtbaan. Dit is waar Behavior-Driven Development (BDD) om de hoek komt kijken, een filosofie die niet alleen softwareontwikkeling versnelt, maar ook de communicatie en samenwerking tussen teams en klanten verbetert.
De vijf stappen van BDD en hoe Lemon het implementeert:
1) Gedrag beschrijven
Met BDD begint alles met het beschrijven van het gewenste gedrag van de software. Standaard beginnen we bij Lemon met het bouwen van een roadmap van alle gedragingen binnen de app. Dit gaat van het inloggen aan het begin tot alle acties die de gebruiker wil doen binnen de app zelf.
2) Stapdefinities schrijven
Voordat we iets doen, hebben we een vergadering met alle mensen die betrokken zijn bij het project, de Three Amigos. Binnen Lemon betrekken we de ontwikkelaar, klant en productarchitect bij deze vergadering. Daar bespreken we de eerder gemaakte acties en veranderen ze in werkbare use cases om een gedeeld begrip te creëren en de acceptatiecriteria te bepalen.
Laten we “inloggen” uit de vorige stap als voorbeeld nemen. Er zijn meerdere manieren waarop een gebruiker kan inloggen en afhankelijk van wat voor soort gebruiker inlogt, kan het gedrag verschillend zijn. Het kan bijvoorbeeld blijken dat een gebruiker met een beheerdersrol na het inloggen op een andere pagina terecht moet komen. Deze use cases worden vertaald naar scenario's die stappen bevatten die een gebruiker moet nemen om de actie uit te voeren. Deze worden gebundeld in een feature-bestand. Binnen Lemon gebruiken we Gherkin om deze scenario's op te schrijven, een taal met veel ondersteuning voor testen in bijna alle programmeertalen.
Het scenario voor het inlogvoorbeeld zou er ongeveer zo uit kunnen zien;
Het is een kunst om deze scenario's te schrijven, waarvoor het BRIEF-principe wordt gebruikt.
- Business Language: Scenario's moeten worden geformuleerd met woorden die rechtstreeks uit het bedrijfsdomein komen. Hierdoor kunnen alle teamleden, ook degenen die niet technisch onderlegd zijn, de scenario's gemakkelijk begrijpen. Het vermijden van jargon en technische terminologie is essentieel om de betrokkenheid van het business team te bevorderen.
- Real data: De functiebestanden moeten echte mogelijke gegevens bevatten in plaats van willekeurige tekst zoals lorum ipsum. Dit zorgt ervoor dat de scenario's realistisch zijn en beter begrepen kunnen worden door alle belanghebbenden. Het gebruik van echte gegevens helpt ook bij het identificeren van potentiële problemen of randgevallen die anders misschien over het hoofd worden gezien.
- Intention revealing: Scenario's moeten de intentie onthullen van wat de actoren in het scenario proberen te bereiken, in plaats van zich te richten op het mechanisme van hoe ze dat gaan bereiken. Door de nadruk te leggen op het “wat” in plaats van het “hoe”, kunnen scenario's de beoogde functionaliteit beter illustreren en misverstanden voorkomen.
- Essential: Scenario's moeten zich richten op het illustreren van één regel of functionaliteit. Elementen die niet direct bijdragen aan dit doel moeten worden verwijderd om de focus te behouden en de scenario's duidelijk en beknopt te houden. Het doel is om het gewenste gedrag van de applicatie te verduidelijken zonder te worden afgeleid door onnodige details.
- Focused: Elk scenario moet gericht zijn op het illustreren van één specifieke regel of gedrag van de applicatie. Dit zorgt voor een duidelijke en gestructureerde aanpak, waarbij elk scenario één op één overeenkomt met een specifieke functie of functionaliteit van de applicatie. Op deze manier kunnen teams zich richten op het begrijpen en implementeren van één gedrag tegelijk, waardoor de ontwikkelinspanningen worden geoptimaliseerd.
En als bonus kun je BRIEF zelf zien als een regel. Houd je scenario's zo beknopt mogelijk.
Zodra al deze scenario's zijn gemaakt, valideren we ze opnieuw in een Three amigos vergadering. Dit zorgt ervoor dat elke stakeholder ze begrijpt en geeft de mogelijkheid om eventuele fouten en misvattingen te herstellen.
3) Uitvoeren en falen
Zodra het bestand met functies is besproken en beoordeeld, kunnen ontwikkelaars ermee aan de slag en beginnen met ontwikkelen. Het featurebestand wordt vertaald naar tests, waarbij elke stap van een scenario een test vertegenwoordigt.
In de vorige stap hebben we Gherkin gebruikt als taal voor het featurebestand. Hierdoor kunnen we bij Lemon eenvoudig Cucumber acts gebruiken als tool voor het koppelen van tests aan individuele stappen die in het Gherkin-bestand staan.
Bij Lemon gebruiken we testgedreven ontwikkeling. Neem ons admin login voorbeeld: als we de functionaliteit eerst zouden implementeren en dan testen, is er een grote kans dat de test, vooral een die de huidige pagina controleert, consequent succes zou aangeven. Om dit probleem te vermijden, schrijven we bij Lemon eerst Cucumber-tests voordat we functionaliteit implementeren. Deze aanpak helpt de kans op misleidende testresultaten te verkleinen.
4) Schrijf code om door de stap te komen
Nu de tests geschreven zijn, kunnen we de code schrijven om ze te laten slagen. Zorg er bijvoorbeeld voor dat de gebruiker kan inloggen en dat admins op hun eigen scherm terechtkomen.
5) Uitvoeren en slagen
Tot slot worden de testcases opnieuw uitgevoerd en ze zouden nu allemaal moeten slagen, wat aangeeft dat de software correct functioneert volgens de specificaties. Dankzij ons gebruik van Cucumber kunnen we deze resultaten exporteren naar een mooi rapport.
Voordelen voor belanghebbenden:
BDD biedt voordelen voor alle belanghebbenden binnen een project. BDD zorgt voor een meer gestroomlijnd ontwikkelingsproces met levende documentatie, minder misverstanden en een betere samenwerking tussen teamleden en belanghebbenden. Bovendien halen belanghebbenden afzonderlijk een aantal voordelen uit BDD;
Product Architect / Functioneel Analist:
- Onderhoudt de status van projecten door middel van levende documentatie.
- Heeft overzicht over alle functies.
- Verbeterde communicatie met alle belanghebbenden door het gebruik van Ubiquitous taal.
- Blijft voortdurend betrokken via Three Amigos
- Meer controle over waarvoor geautomatiseerde tests worden geschreven.
- Vroegtijdige validatie van acceptatiecriteria.
- Vermindert handmatig testen en zorgt voor snellere feedback over softwarekwaliteit.
-
Ontwikkelaar
Beter begrip van verwachtingen.
Gedeeld begrip van vereisten.
Vroege feedback.
Gemakkelijk identificeren wat er kapot gaat bij de ontwikkeling van nieuwe functies.
BDD-testen kunnen dienen als documentatie, waardoor onboarding eenvoudiger wordt.
Verhoogde ontwikkelingsefficiëntie.
Geautomatiseerde testgevallen.
BDD-testgevallen: leesbaar, geverifieerd, besproken.
Klant:
Kan misverstanden gemakkelijker corrigeren.
Behoudt deelname aan het project.
Duidelijk gedefinieerde functionaliteit met snellere validatie => minder fouten en reparatiekosten.
Transparantie in het ontwikkelproces door levende documentatie => heeft overzicht over alles wat er gebeurt.
Verkoop:
Kan aangeven wat er gedaan is in een project.
Heeft documentatie over een project die ze kunnen begrijpen.
Kan deze voordelen aan potentiële klanten verkopen.
De rapporten dienen als gemakkelijk te delen voorbeelden van hoe het werkt.
In een notendop biedt Gedragsgedreven Ontwikkeling een gestructureerde en gezamenlijke benadering van softwareontwikkeling die niet alleen de kwaliteit en efficiëntie van het ontwikkelingsproces verbetert, maar ook de communicatie en betrokkenheid van alle belanghebbenden.
.svg)
.svg)
.png)
.png)