A viselkedésvezérelt fejlesztés (Behavior Driven Development, BDD) egy agilis szoftverfejlesztési folyamat, amely ösztönzi az együttműködést a fejlesztők, a QA és a nem műszaki vagy üzleti résztvevők között egy szoftverkészítő folyamatban.

Miben segít a viselkedésvezérelt fejlesztés?

A BDD ösztönzi a csapatokat, hogy beszélgetéssel és konkrét példákkal hivatalossá tegyék az alkalmazás működésének közös megértését. A tesztvezérelt fejlesztésből (TDD) alakult ki. A viselkedésvezérelt fejlesztés ötvözi a TDD általános technikáit és elveit a tartományvezérelt tervezés és objektumorientált elemzés és tervezés ötleteivel, hogy a szoftverfejlesztő és -kezelő csapatok számára megosztott eszközöket és közös folyamatot biztosítson a szoftverfejlesztésben való együttműködéshez.

Hogyan kapcsolódik a BDD a user story-hoz?

Rövid bevezető rész a már ismert szerkezettel: „Én, mint(user szerep) azt szeretném, hogy (cselekmény) azért, mert (üzleti érték).„.

 „Én, mint egy autó tulajdonos, azt szeretném, hogy az autó magától meghatározza a sebességhatárt és álljon be erre, azért, mert így nem kell figyelnem a sebességre és nem lesz gyorshajtásom.”

BDD Elfogadási kritériumok a story-hoz (Acceptance criteria)

Minden user storynak valamilyen módon a következő struktúrát kell követnie:

• Cím
• Narratíva

A narratíva minden egyes forgatókönyvének leírása a következő szerkezettel:

Given – Adott: a forgatókönyv elején, egy vagy több záradékban szereplő kezdeti környezet;

When – Mikor: a forgatókönyvet kiváltó esemény;

Then – Ezután: a várt eredmény, egy vagy több záradékban.

A viselkedésvezérelt elfogadási kritérium példák

Elfogadási kritériumok a példánkhoz, amiben láthatjuk, hogy a BDD narratíva mennyivel rugalmasabb, könnyebben érthető és pontosabb megközelítést adhat:

„Adott egy sebességhatár, mikor az autó sebessége eléri, azután álljon be közel a határhoz, de ne lépje át„.

És

„Adott, amikor az autó halad az úton, mikor a sebességhatár változik, ezután, a sebesség változzon, de ne váltson ki hirtelen erőhatást„

Az agilis fejlesztések során a Product Owner, a fejlesztők és a tesztelők közös megértéssel csökkentik a rework típusú veszteségek kockázatát és közösen határozzák meg az elfogadási teszteket, amiket rögzítenek a story-kban, úgy, hogy minden résztvevő hozzá tudja tenni a saját területének követelményeit (üzlet, technológia, tesztelés, fejlesztés). És mivel közösen határozzák meg, így az információáramlás nem sérül.

Elfogadási tesztek

Az elfogadási tesztek az alábbiak lehetnek:

„Adott, a sebességhatár, ami 50 km/h, mikor az autó halad az úton, ezután a sebesség essen 49-50 km/h óra közé.”

És

„Adott, a sebességhatár, ami 50 km/h, mikor a sebességhatár változik 30 km/h-ra, ezután a fékezési sebesség legyen 5 méter/másodperc.”

A user story-knak több formája is van, egy későbbi cikkünkben majd azzal foglalkozunk, hogy az FDD rendszerben hogyan néz ki.

Szerző: Bazsi