A BDD (Behavior Driven Development, vagyis Viselkedés vezérelt fejlesztés) egy agilis módszertan, ami a TDD (Teszt vezérelt fejlesztés) kiterjesztése. Lényege, hogy nagyon rövid fejlesztési ciklusokat ismételget, így a követelményeket tesztesetekként is meg lehet fogalmazni, illetve, hogy a kódot is a teszt esetekhez mérten írják meg, így az át tud menni a teszten.
Biztosan elméláztál már azon, hogy milyen jó is lenne érteni a kódot, vagy hogy kellene egy olyan fogalomtár, aminek az elemeit egyaránt használja QA-s, BA és fejlesztő és a fogalmak mindenkinek ugyanazzal a jelentéssel bírnak.
Itt jön a képbe a BDD. Sőt, még eggyel tovább is megy: nem csak a BA-QA-fejlesztő csapatok beszélnek egy nyelvet, hanem az ügyfél is! Mindenki olyan dokumentációt használ, ami hétköznapi nyelven íródott és amit minden résztvevő megért. Ennek eredményeképp a dokumentációk végrehajtható specifikációkká alakíthatók, amik majd egyben UAT-ként is felhasználhatóak lesznek a későbbiekben.
Mindez eddig nagyon jól hangzik, de a gyakorlatban hogyan lehet megvalósítani?
A válasz: Uborka! Vagyis Gherkin. A Gherkin az a nyelvezet, aminek a segítségével funkciókat, forgatókönyveket, lépéseket írhatunk le, megfogalmazhatjuk a konkrét követelményeket.
Jó-jó, de ez eddig még mindig csak elmélet volt és nem láttunk semmi kézzelfoghatót!
Jöjjön a gyakorlat: a Gherkin nyelvű fájlok egyszerű szövegfájlok. A Gherkin legfontosabb kulcsszavai a következők: Feature, Scenario, Scenario Outline, Given, When, Then, And, But.
A Gherkin három kulcsszót használ az összefüggések, az események és az eredmények leírására: Given (Amennyiben) – az összefüggések meghatározására, When (Ha) – a műveletek végrahajtásához, Then (Akkor) – az eredmény ellenőrzésére.
Például: Scenario – Pénzfelvétel bankszámláról
- Amennyiben 100 dollár van a számlámon
- Ha szeretnék felvenni 20 dollárt
- Akkor 20 dollárt ki kell adnia a bankautomatának
Az AND és BUT szavakkal tovább lehet részletezni a lépéseket:
- Amennyiben 100 dollár van a számlámon
- De a kártyám érvénytelen
- Ha szeretnék felvenni 20 dollárt
- Akkor a kártyámat nem kapom vissza
- És fel kell vennem a bankkal a kapcsolatot
A Feature kulcsszó egy szoftver funkció leírására és a kapcsolódó forgatókönyvek csoportosítására szolgál.
Egy vagy több scenario/forgatókönyv tartozik minden feature-höz, pl. Pénzfelvétel bankszámláról, Pénzfelvétel bankszámláról érvénytelen kártyával.
Ha létrehozunk forgatókönyveket különböző be- és kimenetek alapján, előfordulhat, hogy olyanok jönnek létre, amelyek csak az értékeikben különböznek. Erre jó megoldás lehet a scenario outline. Ez egy sablon, amiben a változókat kell csak felsorolni.
Ezek után már csak egy kérdésem maradt: hogyan működik a teljes folyamat egy csapaton belül?
A fejlesztés kezdetétől együtt gondolkodik a csapat, sok esetben az ügyfél részvételével, hogy meghatározzák az új feature tulajdonságait (hogy nézzen ki, hogy működjön, hogyan ne működjön stb.), ami azért is jó mindenkinek, mert sokkal kevesebb lesz a félreértés, sokkal pontosabban lehet az ügyfél igényeihez igazodni, így rengeteg hiba már az elején kiküszöbölhető.
Második lépésként a megbeszélteket felhasználói esetekbe gyűjtik és gherkin formátumban létrehozzák a teszteseteket, ez lesz a specifikáció.
A tesztesetek alapján írják meg a fejlesztők a kódot, sokszor párhuzamosan már ebben a fázisban megírják az automatizált teszteket is, ezután jön a klasszikus tesztelési fázis.
Amint egy-egy funkció készen van, be is mutatják, így folyamatos a kontakt az ügyféllel és egész kicsi egységenként kapja a csapat a visszajelzést.
Tesztelői szempontból a BDD előnyeként a dokumentációban használt fogalmak hétköznapiságát és ezáltal egyértelműségét emelném ki, a „közös nyelvet”, amit mindenki ért. Az egyszerűség miatt a kódoláshoz vagy automatizáláshoz kevésbé értő tesztelők is könnyen megtanulhatják így a tesztesetek automatizálását, be tudnak segíteni ebbe a folyamatba is. Szerintem ezek miatt jó a BDD a tesztelőnek.
Nincs több kérdésem. Meggyőztél!
Ha viszont maradt szakmai kérdésed, akkor érdemes feliratkoznod hírlevelünkre, hiszen így rendszeresen landolnak majd újabb és újabb szoftvertesztelésről szóló cikkek a postafiókodban! 🙂
