BDD - från best practices till vanliga fallgropar

BDD (Behavior Driven Development) är en metod som populariserades av Dan North år 2003. Den bygger vidare på och kompletterar TDD (Test Driven Development).

Varför använda BDD?

BDD togs fram just för att hantera vanliga problem kring specifikationer i agila projekt:

Det saknas en formell beskrivning av kontexten
Specifikationer kan tolkas olika beroende på roll eller person
Specifikationerna är inte alltid uppdaterade

BDD är därför en agil metod som syftar till att synkronisera alla som är involverade i utvecklingen av en funktion, så att man har en gemensam förståelse för vad som faktiskt ska byggas. Målet är att utforma acceptanstester som illustrerar beteendet för en funktion, med hjälp av exempelvis 3 amigos-möten eller example mapping. BDD sker generellt i tre steg - upptäckt, formulering och automatisering.

Så fungerar det i praktiken

De inblandade rollerna (t.ex. produktägare, utvecklare och testare) samarbetar för att ta fram konkreta exempel som visar hur funktionen ska bete sig – det är upptäcktsfasen, ofta i form av ett 3 amigos-möte. Här skapas en gemensam förståelse för behovet, och man skriver scenarier för att bekräfta att alla acceptanskriterier uppfylls.

Exemplen formuleras i ett gemensamt språk, Gherkin, som är enkelt att förstå för olika typer av roller. Gherkin gör det möjligt att skriva strukturerade tester i ett naturligt språk, med tydlig syntax:

GIVEN ett visst sammanhang, WHEN en åtgärd utförs, THEN uppstår ett resultat 1 AND ett resultat 2.

Denna strukturerade beskrivning av beteendet kan sedan användas i ett verktyg som Cucumber, vilket tolkar Gherkin-språket och kör automatiserade acceptanstester utifrån dessa exempel. Det är automatiseringsfasen.

Vanliga avvikelser och missförstånd

BDD används idag i många företag för att testa funktionalitet i nära samarbete med verksamheten. Men trots att syftet är att skapa en gemensam förståelse, finns det många missuppfattningar som kan leda till att man använder BDD på fel sätt.

BDD reduceras till testautomatisering

När BDD enbart ses som ett sätt att automatisera tester tappar man den verkliga styrkan – att alla inblandade får samma bild av vad som förväntas.

Scenarier skrivs bara av produktägare eller testare
Även om det finns exempel, saknar de ofta djup eller kvalitet eftersom de inte tagits fram gemensamt eller granskats ur flera perspektiv.

Acceptansscenarier skrivs inte alls
Ibland hålls möten om funktionalitet, men inga scenarier dokumenteras. Då går viktig information förlorad. Det leder också till att fler personer måste delta i flera möten, vilket kostar mer tid.

Tester som inte är begripliga för alla
BDD-tester ska kunna förstås av hela teamet (och ibland även andra delar av organisationen). Om testerna är otydliga eller tekniska förlorar man syftet: att alla delar samma förståelse.

BDD sker under sprinten
Att göra BDD "under sprinten" betyder inte nödvändigtvis under utvecklingen, men även om det sker före själva kodandet så påverkar det teamet – man har ofta redan förbundit sig att leverera en user story man kanske inte helt förstått.

Att använda Gherkin betyder inte att man gör BDD
Gherkin är bara ett språk. BDD kan ta andra former. Det är också fullt möjligt att skriva tester i Gherkin som inte alls följer BDD-principer – till exempel med verktyg som Karate, där testerna inte är begripliga för icke-tekniska roller.

Sammanfattning

Innan sprinten börjar bör BDD-praktiken fokusera på upptäckt - att säkra en gemensam förståelse av kravet bland alla involverade. Denna förståelse formuleras i form av exempel, acceptanskriterier och acceptansscenarier, som därefter används i verktyg för att automatisera testerna.

Att följa dessa steg hjälper team att undvika BDD-fallgropar och framför allt att undvika den begreppsförvirring som ofta råder kring vad BDD faktiskt är.

Gilles Ménède

INSIKTER & NYHETER Håll dig uppdaterad!

Få kunskap, nyheter, inspiration, tips och inbjudningar om kvalitetssäkring direkt i din inkorg.

share the article