BDD: från bästa praxis till avvikelser

Skriven av Gilles Ménède | Jul 16, 2026 7:55:30 AM

BDD (Behaviour Driven Development) är en metod som populariserades av Dan North år 2003 och som härstammar från TDD (Test Driven Development), vilken den kompletterar.

Varför använda BDD? Just för att ta itu med de vanliga problemen med specifikationer i agila utvecklingsmetoder:

Ingen formell förklaring av sammanhanget,
Specifikationer som kan tolkas olika av olika roller eller aktörer,
De är inte nödvändigtvis uppdaterade.

BDD är därför en agil metod som syftar till att synkronisera de olika aktörerna som utvecklar en funktion med vad den ska göra. Syftet med BDD är att utforma acceptanstester som illustrerar funktionens beteende, med hjälp av metoder som ”de tre vännerna” eller exempelkartläggning. BDD-metoden genomförs vanligtvis i tre steg: upptäckt, formulering och automatisering.

Rätt tillämpning

Aktörerna samordnas med hjälp av gemensamt utformade exempel som illustrerar funktionalitetens beteende: detta är upptäcktsfasen, som ofta uppnås genom ett möte mellan de tre vännerna (kund-, utvecklare- och testarprofiler), vilket ger en gemensam förståelse av behovet och gör det möjligt att skriva acceptansscenarier för att validera acceptanskriterierna.

Dessa exempel formuleras med hjälp av ett gemensamt språk, Gherkin, som lätt förstås av de olika rollerna bland de tre vännerna. Gherkin-språket är utformat för att skriva strukturerade tester i ett naturligt språk, och är a priori begripligt för alla. Gherkin-tester skrivs med de fyra grundläggande elementen: GIVEN / WHEN / THEN … AND (GIVEN ett visst sammanhang, WHEN jag utför en åtgärd, THEN får jag ett resultat1 AND ett resultat2).

Utifrån denna strukturerade (och formaterade) formulering av funktionalitetens beteende är det möjligt att integrera dessa exempel i ett programverktyg, till exempel Cucumber, som tolkar Gherkin-språket för att köra automatiserade acceptanstester anpassade efter dessa exempel. Detta är automatiseringsfasen.

Dess avvikelser

BDD används idag i många företag för att testa beteendet hos vissa funktioner i nära samarbete med användarna. Men även om BDD används för att uppnå en gemensam förståelse av behoven, finns det fortfarande en del oklarheter kring denna agila metod, vilket kan leda till vissa missbruk. Vilka är dessa?

BDD ses enbart som automatisering

I det här fallet går vi miste om det väsentliga bidraget från BDD: möjligheten för alla att ha samma förståelse för vad som förväntas.

Scenarierna skrivs och utformas enbart av produktägaren eller testaren.

I det här fallet finns det visserligen exempel. Tyvärr är kvaliteten på dem ofta bristfällig, eftersom de inte har granskats av personer med olika kompetensprofiler.

Underlåtenhet att skriva godkännandescenarier

Ibland hålls samordningsmöten, men i slutändan tar det inte fram något scenario. Detta är problematiskt i den meningen att mycket av informationen går förlorad eftersom den glöms bort. Det tvingar också fler personer att delta i dessa möten, vilket kräver en större insats.

Tester som inte är begripliga för alla profiler

Ett BDD-test måste förstås av alla i teamet (och ibland även utanför). Att skriva tester som inte förstås av alla garanterar inte att alla förstår samma sak. Generellt sett gör det det inte heller möjligt för verksamheten att verkligen validera det som ska utvecklas.

BDD skapas under sprinten

Under en sprint betyder inte under utvecklingen. Men även när BDD genomförs före utvecklingen påverkar denna process teamet, som har varit tvunget att åta sig att leverera ett användarfall som det kanske inte har förstått fullt ut.

Att använda Gherkin som BDD

Gherkin är ett språk. BDD kan ta andra former… precis som det är möjligt att köra tester i Gherkin som inte är BDD (t.ex.: verktyget Karaté erbjuder tester i Gherkin som inte kan förstås av funktionella profiler).

Innan sprinten inleds består BDD-metoden i att, genom utforskning, säkerställa en gemensam förståelse av kravet hos alla inblandade aktörer. Denna förståelse formuleras genom exempel, acceptanskriterier och acceptansscenarier, som sedan implementeras i ett verktyg för utformning och körning av automatiserade tester.

Att tillämpa de olika stegen i denna metod kommer att bidra till att motverka BDD-avvikelser och, framför allt, den förvirring som för närvarande råder kring de olika termerna som omger BDD-konceptet.

Visa hela inlägget