ORDINA BLOGT

BDD II -Specification by Example

Bij BDD is het belangrijk om concreet te maken wat de wens van de gebruiker is. Specification by Example kan hierbij helpen.

  • Kaspar van Dam
  • 2 mei 2016

Enige tijd geleden heb ik bij een klant diverse Three Amigo's sessies begeleid. Het gehele team, inclusief de Product Owner was aanwezig. Iedereen zag het belang in van de sessie en, na enige toelichting, was het iedereen helder wat het doel van de sessie was. Het bleek echter alsnog lastig om zaken concreet te maken zonder direct te verzanden in discussies over de mogelijke implementatie van de oplossing...
Afgelopen week heb ik reeds een blog geplaatst over Three Amigo's. Daarin heb ik verteld over het belang van het gezamenlijk bepalen wat deze concrete wens van de eindgebruiker is en hierbij Gedrag en Implementatie bewust te scheiden. Juist dit concreet maken van het gedrag van de gebruiker en het gedrag van het systeem als antwoord daarop kan complex zijn. Het genoemde team heeft Specification by Example gebruikt om voldoende helder te krijgen wat de eindgebruiker echt wil en te bepalen wat er gebouwd moest worden om de eindgebruiker daarbij te helpen. Maar wat is Specification by Example nu precies?

BDD deel II - Specification by Example

Specification by Example is een term bedacht door Gojko Adzic. Hij heeft deze naam gekozen in plaats van een term als Agile Acceptatie Testen omdat het fenomeen Agile meer en meer gebruikt werd/wordt als toverwoord. Als Silver Bullet welke alle problemen zou oplossen. De gedachte achter Specification by Example is echter meer. Het is een praktische invulling van het BDD gedachtegoed, dat op zijn beurt weer een praktische invulling is van wat men oorspronkelijk met het Agile Manifest voor ogen had: Het iteratief ontwikkelen van software waarbij communicatie en samenwerking zwaarder wegen dan processen en methodieken met als doel om zo snel mogelijk zoveel mogelijk business value te creëren voor de eindgebruiker.

Dit is ook terug te vinden in de ondertitel van het boek dat Gojko over Specification by Example geschreven heeft: " How successful teams deliver the right software". De nadruk ligt op het leveren van de juiste software. Ofwel, hetgeen waar de eindgebruiker echt op zit te wachten. Er wordt dan ook een duidelijk onderscheid gemaakt tussen "Building the product right" en "Building the right product". Een software ontwikkeling project is pas succesvol als aan deze beide voorwaarden voldaan wordt.

Binnen BDD is het van groot belang om vroeg in het proces helderheid te krijgen wat de gebruiker echt wil en waar software dus aan moet voldoen om de gebruiker daarbij te helpen. Om dit te bereiken is het essentieel om heel concreet te maken wat het business doel is, wat de scope is, en dit vervolgens middels het eerder omschreven Three Amigo's principe  te vertalen naar specificaties op basis van concrete voorbeelden. Zogenaamde Key Examples. Deze Key Examples kunnen op hun beurt weer gebruikt worden om middels refinement te komen tot een complete specificatie op basis van voorbeelden en van daaruit kan de software gebouwd en getest worden. Op deze manier zijn functionele requirements, specificatie en de acceptatie testen hetzelfde en wordt voorkomen dat er gaandeweg miscommunicatie en/of misinterpretatie ontstaat. Dit is mogelijk omdat er door alle betrokkenen in 1 taal gesproken wordt. Hier zal een volgend deel van deze blog reeks dieper op in gaan.

Specification by Exmaple diagram

De specificatie die uit dit proces ontstaat is levende documentatie die door alle betrokkenen binnen het software ontwikkeling proces gebruikt kan worden als levende documentatie en als basis voor alle vervolg stappen bij het daadwerkelijk ontwikkelen van de juiste software. Voor meer informatie over Specification by Example verwijs ik graag naar het boek van Gojko Adzic: Specification by Example uit 2012 en uitgegeven door Manning Publications Co. (ISBN: 9781617290084).

Uiteraard geldt ook hier dat ik, of een collega BDD consultant van Ordina, er meer over kan vertellen en/of een dergelijke Three Amigo's sessie kan begeleiden. Neem hiervoor contact op met mij of de eigen Ordina contactpersoon.

Over de auteur:

Kaspar van Dam

Kaspar van Dam is test(automatisering) consultant bij Ordina en adviseert collega's en klanten over vraagstukken rondom de thema's agile testing, behavior driven development (BDD), testautomatisering en meer.