Auteur: Kimberly Snoyl & Kaspar van Dam ● bdd@testnet.org
Redactie: Paul Beving
In januari 2021 heeft Kaspar van Dam de werkgroep Behaviour Driven Development opgericht naar aanleiding van het enthousiasme rondom de gelijknamige thema-avond diezelfde maand. De werkgroep heeft als doel om aan de hand van conversatie en concrete voorbeelden tot een gezamenlijk begrip te komen van BDD. Het afgelopen jaar hebben we acht bijeenkomsten gehad, waarvan één op locatie. Bij de laatste thema-avond van 2021 hebben we verteld waar we het afgelopen jaar mee bezig zijn geweest. Bij deze kun je het nogmaals nalezen als je er niet bij was. Wil je de werkgroep komen versterken, neem dan contact met ons op via bdd@testnet.org.
BDD is niet een vastomlijnd framework.
Er bestaat geen theorieboek dat vertelt hoe het moet, een ‘single source of truth’ ontbreekt. Juist deze vrijheid en pragmatiek is een kracht van BDD, maar dit maakt het ook lastig te duiden wat het nu precies is (waardoor er veel misverstanden of anti-patterns ontstaan). Wij als werkgroep BDD willen voor onszelf helder krijgen wat BDD nu werkelijk is en vooral ook hoe dit toe te passen. We zoeken naar concrete handvatten voor BDD in de praktijk met een focus niet enkel op test, maar juist ook op het vlak van (deliberate) discovery, requirements en documentatie (living documentation).
Er is een aantal misverstanden rondom BDD
- BDD wordt onterecht vaak gezien als testen. Wellicht komt dit door een onhandig gekozen naam. Volgens Dan North had hij het achteraf bezien liever “Example-Guided Design” genoemd. BDD is eigenlijk business analyse, maar dan als team effort (shared understanding). Testen is daarbij ‘slechts’ bijzaak, maar wel een heel belangrijk voordeel omdat specs direct gekoppeld zijn aan test. Het is een hardnekkig misverstand dat BDD een testmethodiek is omdat het toch vaak echt een ‘testfeestje’ is. Testers zijn vaak degenen die BDD in het team introduceren en er is nog altijd geen duidelijke informatiebron die eenduidig toelicht wat BDD wel/niet is. Helaas leidt dit in de praktijk tot problemen, zoals:
- specificaties zijn vaak enkel testen, daadwerkelijke specificatie/documentatie ontbreekt;
- er wordt niet meer getest dan enkel de examples (specificatie) waardoor testdekking ontbreekt;
- grote berg feature files zonder structuur;
- zich gedwongen voelen om alle tests in Gherkin te schrijven.
- BDD wordt vaak onterecht benoemd als testautomatisering of (A)TDD. Dit komt omdat de tooling voor BDD (met name Cucumber en Specflow) vaak wordt gezien als tooling ten behoeve van testautomatisering. Ook spreekt de ‘Given-when-then’-notering misschien wel het meest tot de verbeelding en denkt men dat dit de essentie is van BDD waardoor automatiseren (in Cucumber) een doel op zich wordt. Dit is gelijk ook één van de redenen dat dit misverstand hardnekkig aanwezig blijft: de ‘Given-when-then’-Scenario’s worden vaak testscripts / automatiseringsscripts.
Wat is BDD dan wél?
BDD is in essentie het slaan van een brug tussen business en agile team met behulp van een gezamenlijke (domein) taal, vergelijkbaar met wat Domain-Driven Design (DDD) poogt te doen. BDD vormt de basis voor de te ontwikkelen en te testen software, maar is ook de (levende) documentatie ervan. Het doel is een gedeeld begrip (shared understanding) creëren en dit vastleggen in één punt van waarheid (single source of truth).
Praktijkcasus
Onder de meeste deelnemers van de werkgroep ontbrak het aan ervaring met BDD en veel leden hadden de wens om meer ‘goeie’ ervaring met BDD op te doen. Ervaring met BDD zoals het écht bedoeld is en niet volgens eerder genoemde misverstanden die in de praktijk nog erg veel voorkomen. De praktijkcasus waar we in de werkgroep BDD aan werken doen we in samenwerking met de start-up Equifacts (www.equifacts.nl). Het eerste echte leerplatform voor de paardensport (zowel particulier als meer professioneel) waarbij een brug geslagen wordt tussen de wetenschappelijke kennis die ruim beschikbaar is en de mensen die zich daadwerkelijk bezighouden met de sport. Vanuit de werkgroep zijn we aan de slag gegaan met diverse aan BDD gerelateerde werkvormen, te beginnen met Impact Mapping en Event Storming. Samen met Equifacts kregen we zo snel een helder beeld van het doel van het platform, wie de (potentiële) gebruikers waren en wat deze precies nodig hadden. Van daaruit hebben we middels een Event Storm gezamenlijk ontdekt dat er veel meer behoefte bestond aan een stuk community-vorming en dat een stuk ‘gamification’ daar een belangrijke rol in kon spelen. We hebben daarvoor een Event Storm uitgewerkt met het betrekking tot het belonen van bepaalde acties op het platform met zogeheten fysieke en/of virtuele rozetten. Het komende jaar gaan we verder met deze casus, ook al is het platform inmiddels al online (dus als je iemand kent die zich bezighoudt met paardensport: vertel het door!). We gaan daarvoor aan de slag met Example Mapping, Specification by Example en willen uiteindelijk ook kijken of we een stuk testautomatisering kunnen inrichten.
De werkgroep BDD in 2022: ‘We need you!’
Er zijn dus ook voor dit jaar grootse plannen. In de loop van het jaar willen we de resultaten wederom gaan delen in een Testnet event, maar daarvoor moet er nog een hoop gebeuren. En dat betekent dat we nieuwe leden kunnen gebruiken!
- We komen elke zes weken samen
- Wisselend tussen maandag- en dinsdagavond
- Meestal online en een aantal keer per jaar bij het NBC congres centrum Nieuwegein
- Momenteel hebben we een kleine maar open en enthousiaste werkgroep met zowel ervaringsdeskundigen als geïnteresseerden
Heb je kennis/ervaring met BDD of is het iets waar je je altijd al eens in hebt willen verdiepen? Neem dan contact op via BDD@testnet.org voor meer informatie en/of om je aan te melden voor de Testnet werkgroep BDD.