BDD: från bästa praxis till 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).