ORDINA BLOGT

BDD deel IV - 1 Taal

  • Kaspar van Dam
  • 2 mei 2016

Momenteel is de nieuwe lichting Young Professionals druk bezig met de basis opleiding.Wekenlang worden zij gebombardeerd met kennis en ervaring zodat ze straks een vliegende start kunnen maken met de carrière. Ik mag sinds enige tijd alle Young Professionals die bij Ordina aan de slag gaan laten kennismaken met Behaviour Driven Development. Afgelopen week heb ik deze training weer mogen geven als onderdeel van de YP leergang. Het was, zoals eigenlijk altijd, een enorm inspirerende sessie. Goede discussies en men heeft veel geleerd tijdens de praktijkopdrachten waarbij het 3 Amigo principe en het scheiden van gedrag en implementatie centraal staat. De belangrijkste les van de dag? Zorg dat het gehele team, inclusief de Product Owner, één taal spreekt.

BDD deel IV: 1 taal

De afgelopen weken heb ik een drietal blogs geplaatst. Over 'Three Amigo's', 'Specification by Example' en '(A)TDD'. De centrale boodschap in al deze blogs was dat communicatie dé centrale spil is van Behaviour Driven Development en tevens dé succesfactor om niet alleen software juist te bouwen - maar ook de juiste software te bouwen.

In dit laatste blog van het vierluik over BDD wil ik het belang benadrukken van deze communicatie en vooral het belang om te zorgen dat iedereen één en dezelfde taal spreekt. Vele ICT projecten zijn namelijk mislukt doordat verschillen in interpretatie er voor zorgden dat iedere schakel in de software-ontwikkelingsmachine een ander beeld voor ogen had van het op te leveren eind product.... Wie kent niet het beroemde/beruchte plaatje met de verschillende versies van een schommel aan een boom zoals geïnterpreteerd door de diverse rollen binnen een ICT project? (Voor wie hem niet kent: Google op 'ICT schommel').

Wat mij betreft dé kracht van Behaviour Driven Development is dat het concrete handvatten biedt om te zorgen dat alle teamleden én de business een zelfde taal spreken. Hierbij worden User Stories gezamenlijk concreet gemaakt binnen 3 Amigo sessies (zie mijn eerste deel van het vierluik), verder uitgewerkt tot concrete voorbeelden (tweede deel vierluik) en vervolgens (vrijwel) één op één vertaald naar functionele testen én unit testen volgens het (A)TDD principe (derde deel vierluik). Wellicht het meest effectieve middel dat BDD hiervoor biedt is het zogenaamde 'Gegeven..., Als..., Dan...' principe. Alle concrete voorbeelden (Specification by Example) zijn in deze vorm op te schrijven in scenario's waarbij 'Gegeven' staat voor een bepaalde benodigde uitgangssituatie, 'Als' voor het gedrag van de gebruiker en 'Dan' voor het gedrag dat het systeem als respons dient te geven op het gedrag van de gebruiker.

Wanneer er nu voor gewaakt wordt dat deze scenario's enkel gedrag omschrijven (zowel van gebruiker als systeem) en implementatie (nog) achterwege gelaten wordt is dit vrijwel een garantie dat iedereen binnen het team en binnen de business exact weet wat het einddoel is dat men voor ogen heeft en tevens waarom men dit zo wil. De scenario's kunnen (vaak één op één) vertaald worden naar testgevallen die middels tooling als Cucumber of Specflow omgezet kunnen worden naar testautomatisering. Het enige dat nog moet gebeuren is dan de software bouwen die zorgt dat deze testen daadwerkelijk slagen.

Sim-pel!
Of niet?

Helaas, de handvatten die BDD biedt klinken relatief eenvoudig en voor velen als een open deur - de praktijk leert dat het daadwerkelijk gebruiken van deze handvatten nog altijd zéér uitdagend kan zijn! Met name omdat continu communiceren in het geheel niet zo makkelijk is als het soms lijkt. Hier heb ik eerder over geschreven in een blog en artikel (Java Magazine) met als titel 'Continuous Communication'. Echt effectief communiceren is namelijk iets wezenlijk anders dan een babbeltje maken bij de koffie automaat... Het is van belang dat er binnen het team een cultuur ontstaat van communiceren. Hierin moet iedereen een gelijke stem hebben, gehoord worden en zich ook durven uitspreken. Alles valt of staat bij een stuk wederzijds vertrouwen en het nemen van verantwoordelijkheid (als team, maar tevens als teamlid binnen het team). Kortom, teamwerk. En communicatie, in één taal.

Ook hier geldt dat een BDD training/workshop met het gehele team zinvol kan zijn en/of begeleiding door een BDD coach van buiten het team. Ordina kan hier uiteraard bij helpen, neem daarvoor contact op met mij of de eigen Ordina contactpersoon.

Over de auteur:

Kaspar van Dam

Kaspar van Dam is test(automatisering) consultant bij Improve QS en adviseert collega's en klanten over vraagstukken rondom de thema's Agile Testing, Behavior Driven Development (BDD), testautomatisering, performance testen en meer.