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.
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.
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.”
Minden user storynak valamilyen módon a következő struktúrát kell követnie:
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.
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.
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
