Voorbereiding

1. Behaviour Driven Development

Bekijk onderstaande YouTube video van Ryan Yackel over het verschil tussen gedragsgedreven development (BDD) en traditionele softwareontwikkeling.

BDD vs. Traditional Development (9 minuut 20)

Beantwoord de vragen uit de quiz:

i

Deze quiz helpt je toetsen of je de bron echt hebt bekeken/gelezen en begrepen. Zo niet: bekijk/lees de bron opnieuw. Gebruik deze quiz niet als 'gaming' voor de toets; de toetsvragen zijn inhoudelijk anders.

1. Waarvoor staat de afkorting BDD?

Behaviour Driven DesignBehaviour Driven DevelopmentBehaviour Data DeterminationBusiness Development Directive

2. In welk opzicht is BDD anders dan traditionele software development?

Het vervangt alle handmatige testen door geautomatiseerde testenHet werkt met de Three Amigos, zodat developers vriendschappelijker samenwerkenHet dwingt een strikte taakverdeling af: zakelijke belanghebbenden bepalen het wat, developers het hoeHet stimuleert samenwerking bij het bepalen en realiseren van requirements

3. Wat bedoelt Ryan Yackel met 'siloed'?

Afdelingen werken geïsoleerd; de business legt op wat gebouwd wordt zonder overlegTeams communiceren via Gherkin om samenwerking en begrip te bevorderenOntwikkelaars en testers werken nauw samen, maar sluiten zakelijke belanghebbenden volledig uit van beslissingenEen project wordt in kleine, onafhankelijke deelproducten opgesplitst die elk apart worden opgeleverd en soepel geïntegreerd

4. Wat is het verschil tussen TDD en BDD?

TDD vereist dat business stakeholders tests schrijven, terwijl BDD alleen voor ontwikkelaars isBDD vereist dat business stakeholders tests schrijven, terwijl TDD alleen voor ontwikkelaars isBDD elimineert de noodzaak voor geautomatiseerde tests, terwijl TDD vertrouwt op automatiseringTDD focust op losse code-eenheden, BDD op het gedrag van het systeem als geheel

5. Wat is het verschil tussen BDD en Scrum?

BDD wordt vooral gebruikt bij watervalontwikkeling, terwijl Scrum gangbaar is bij Agile projectenBDD wordt vooral gebruikt bij Agile projecten, terwijl Scrum gangbaar is bij watervalontwikkelingScrum is een methode voor projectmanagement, terwijl BDD een aanpak is voor softwareontwikkelingBDD is een methode voor projectmanagement, terwijl Scrum een aanpak is voor softwareontwikkeling

6. Wie zijn de three amigo's in BDD?

De ontwikkelaar, de product owner en testerDe DB admin, de eindgebruiker en de BDD specialistDe BDD specialist, de BDD test automatiseerder en de BDD developerDe ontwikkelaar, de product tester en de data engineer

7. Is BDD ook een test-driven aanpak?

Ja, je bedenkt eerst het voorbeeld en scenario en schrijft de test, en daarna de functionaliteitNee, BDD begint pas met testen nadat alle functionaliteiten volledig geïmplementeerd zijnJa, maar in BDD test je alleen de gebruikersinterface en niet de onderliggende logicaNee, BDD richt zich uitsluitend op handmatige acceptatietesten door eindgebruikers

Toelichting term silo

Figuur 1 illustreert het 'silo syndroom'. Dit is een term die de (ongewenste) situatie beschrijft waarin afdelingen of teams binnen een organisatie geïsoleerd werken en weinig communiceren met elkaar. Dit kan leiden tot inefficiëntie, vertragingen en miscommunicatie. Het is belangrijk om deze 'silo's' te doorbreken door samenwerking en communicatie tussen teams te bevorderen.

"Phil Ensor (manager bij bandenbedfrijf 'Goodyear') bedacht in 1988 de term “Functional Silo Syndrome” om te beschrijven hoe de meeste organisaties opereren. Hij werd geïnspireerd door de hoge graansilo's uit zijn geboortestreek Illinois, die hem eraan herinnerden hoe afdelingen [...] in het bedrijfsleven vaak werken: gefragmenteerd en geïsoleerd." - marketoonist.com

Figuur 1: Het 'Silo' Syndroom (bron: marketoonist.com, okt 2024)

De silo's in dit geval gaan dus over indeling van medewerkers/afdelingen, niet over hoe je je applicatie opdeelt.

TL;DR

#BDD in a tweet:

Using examples at multiple levels to create a shared understanding and surface uncertainty to deliver software that matters

— Dan North (@tastapod)

notitie

EEN VERTAALD UITTREKSEL VAN PARAGRAAF what is BDD? (CUCUMBER.IO, N.D.)

BDD is een manier van werken om de kloof te dichten tussen stakeholders en developers door:

• Samenwerking tussen verschillende rollen aan te moedigen en een gedeeld begrip van de vereisten op te bouwen
• Het bevorderen van het werken in snelle, kleine iteraties om feedback en de waardestroom te vergroten
• Documentatie te produceren die automatisch wordt gecontroleerd aan de hand van het gedrag van het systeem

Anders gezegd we doen dit door de onderlinge samenwerking te richten op concrete voorbeelden uit de echte wereld die illustreren hoe we willen dat het systeem zich gedraagt. We gebruiken die voorbeelden om ons te begeleiden van concept tot implementatie, in een proces van voortdurende samenwerking.

Figuur 1: BDD-TDD loop

2. BDD - Example Mapping

Een techniek om te komen tot concrete voorbeelden is het houden van een example mapping sessie. Hier gaan we in de aanstaande les mee oefenen, maar lees je vast in op de techniek middels deze introductie van example mapping.

tip

Voor digitaal uitwerken kun je ook deze tool gebruiken: examplemapping.com.

tip

Optionele reflectie op de huidige staat van BDD: Is BDD dying? (Automation Panda, March 6, 2025).

notitie

Een vertaald uittreksel van paragraaf How it works (Cucumber.io, n.d.)

Concrete voorbeelden zijn een goede manier om ons te helpen het probleemdomein verder te verkennen en te begrijpen. Ze vormen een goede basis voor onze acceptatietesten en daarmee ook voor het opstellen van formele scenario's.

Bij het bespreken van deze voorbeelden kunnen dingen naar boven komen die het verdienen om ook vastgelegd te worden:

• regels die een verzameling voorbeelden kunnen samenvatten, of andere beperkingen uitdrukken.
• vragen die niet beantwoord kunnen worden tijdens het gesprek, of aannames die gedaan worden.
• nieuwe user stories die ontdekt of opgedeeld en uitgesteld zijn naar buiten de scope.

We kunnen deze verschillende soorten informatie vastleggen op indexkaarten (post-its) en ze ordenen in een canvas:

• We schrijven de user story op een gele kaart en leggen die bovenaan.
• Elk van de acceptatiecriteria, of regels, wordt op een blauwe kaart geschreven en onder de gele user story kaart geplaatst.
• Voorbeelden om deze regels te illustreren schrijven we op een groene kaart en plaatsen we onder de betreffende regel.
• Vragen die we tijdens de sessie niet beantwoord kunnen krijgen, schrijven we op een rode kaart, zodat we verder kunnen gaan met het gesprek.

We gaan door tot de groep tevreden is en de reikwijdte van het verhaal duidelijk is, of tot de tijd op is (meestal niet meer dan 25 minuten).