Inmiddels hebben veel organisaties de overstap gemaakt van de traditionele waterval methode naar een iteratieve ontwikkelmethode als Agile/Scrum. Een aantal organisaties zijn in hun werkwijze een stap verder gegaan en hebben DevOps geïntroduceerd. Waar de methodiek Agile vooral focust op het tevredenstellen van de klant, richt DevOps zich daarnaast op het dichten van de kloof tussen ontwikkeling en beheer.
Een goede toepassing van Agile leidt tot hogere kwaliteit van het product (software), hogere klanttevredenheid en flexibiliteit voor wijzigingen vanuit gebruikersorganisatie. Vanuit mijn perspectief zijn veel teams door een Agile werkwijze te hanteren in plaats van de traditionele waterval methode, efficiënter en effectiever geworden, met de nadruk op onderlinge samenwerking en communicatie. Toch valt het mij in verschillende organisaties vaak op dat sommige onderdelen binnen het (Agile) project kristalhelder zijn voor het ene teamlid, maar zwarte magie voor een ander. Het gevolg: te veel documentatie, details, miscommunicatie en daardoor ook meer inspanning vanuit verschillende disciplines voor het creëren van een gemeenschappelijk begrip voor het ontwikkelen van software!
In dit blog houd ik me bezig met het beantwoorden van de volgende vragen… Hoe gaan we ervoor zorgen dat alle inspanningen van verschillende disciplines binnen Agile goed op elkaar afgestemd worden om het gewenste product juist te bouwen? Hoe gaan we valideren of hetgeen gebouwd is ook daadwerkelijk voldoet aan de wensen/eisen van de eindgebruikers? Hoe gaan we een definitieve brug slaan tussen Business en IT?
Het antwoord voor mij is: Behaviour Driven Development, hierna te noemen “BDD”! Het doel van BDD is synergie creëren tussen enerzijds het Development Team (IT) en anderzijds de eindgebruiker (Business). Hierbij is het belangrijk om eerst het gedrag van deze gebruiker te specificeren en vervolgens te automatiseren. Het product is uiteindelijk bedoeld voor de eindgebruiker!
BDD is voor mij een recept waarbij je in natuurlijke taal (Given-When-Then) testscenario’s schrijft die begrijpelijk en levend zijn voor alle stakeholders (testers, developers, architecten, analysten, gebruikers, designers). De focus is om de opgestelde acceptatiecriteria in de user stories op hun beurt te automatiseren (Step Defintions). Op deze manier creëer je een gemeenschappelijk begrip tussen verschillende disciplines waarin je effectief en efficiënt met elkaar samenwerkt en communiceert. Een gereedschap waarmee je als team echt verder komt: “Adding value to software testtooling”.
Het is aan het team om samen het BDD-principe te implementeren en te kiezen welk framework het best past binnen Agile. Wel moet er gewaakt worden dat er een duidelijke scheiding wordt gemaakt tussen de intentie van de eindgebruiker en de implementatie van het team.
Zo hebben wij bijvoorbeeld in een van mijn vorige Agile projecten BDD geïmplementeerd met het gebruik van SpecFlow. SpecFlow is een Test Automation Framework dat BDD ondersteunt. Voor meer info, ga naar http://www.specflow.org/. Het voordeel van het gebruik van SpecFlow voor ons was het creëren van levende documentatie voor de stakeholders en focus op geautomatiseerde acceptatiecriteria. De ontwikkelaars zijn meer betrokken bij het testproces en de testers zijn veel actiever en kritischer bij het opstellen van acceptatiecriteria door de businessanalisten. Tegelijkertijd was het een mindset om bugs te voorkomen in plaats van deze te vinden. Op deze manier kregen we meer grip, vertrouwen en overlapping tussen de verschillende disciplines.
Komt de bovenstaande uitdaging je bekend voor en wil je meer weten van BDD, dan beveel ik je graag aan om Specification by Example & Bridging the communication Gap van Gojko Adzic te lezen. In mijn volgende blog zal ik dieper ingaan op het Test Automation Framework BDD met daarin de drie centrale kwaliteitsattributen, namelijk: leesbaarheid, herbruikbaarheid en onderhoudbaarheid!
Comments