facebook-pixel

Hogyan működik a BDD és miért jó ez a tesztelőnek?

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! 🙂

Megosztás

Facebook
LinkedIn
Twitter

Nem szeretnél lemaradni az új bejegyzésekről?

Tartalomjegyzék

sorozatok
Dechandt Dóra

BDD rövid bemutatása

BDD pro és kontra Egyik előző írásunkban (LINK) már kifejtettük, hogyan működik a BDD. Ezúttal az előnyeire és hátrányaira szeretnénk rávilágítani. A BDD (Behavior Driven

Érdekel a tesztelés világa?

Dolgozz velünk hazai és nemzetközi projekteken

egy csoport ember ül egy asztalnál laptopokkal

Várj, ne maradj le legújabb szakmai cikkeinkről

Iratkozz fel hírlevelünkre és minden hónapban elküldjük a legizgalmasabb cikkeket

egy laptop számítógépet tartó szemüveges férfi
egy süti csokireszelékkel
Tájékoztatjuk, hogy a honlap felhasználói élmény fokozásának érdekében sütiket alkalmazunk. A honlapunk használatával ön a tájékoztatásunkat tudomásul veszi.