Sep 11, 2023

A BDD csapdájában

Jellemzően azt gondolják, hogy a BDD egy tesztautomatizálási módszer, valójában nem teljesen az, sőt...

A BDD csapdájában

Interview multiple candidates

Lorem ipsum dolor sit amet, consectetur adipiscing elit proin mi pellentesque  lorem turpis feugiat non sed sed sed aliquam lectus sodales gravida turpis maassa odio faucibus accumsan turpis nulla tellus purus ut   cursus lorem  in pellentesque risus turpis eget quam eu nunc sed diam.

Search for the right experience

Lorem ipsum dolor sit amet, consectetur adipiscing elit proin mi pellentesque  lorem turpis feugiat non sed sed sed aliquam lectus sodales gravida turpis maassa odio.

  1. Lorem ipsum dolor sit amet, consectetur adipiscing elit.
  2. Porttitor nibh est vulputate vitae sem vitae.
  3. Netus vestibulum dignissim scelerisque vitae.
  4. Amet tellus nisl risus lorem vulputate velit eget.

Ask for past work examples & results

Lorem ipsum dolor sit amet, consectetur adipiscing elit consectetur in proin mattis enim posuere maecenas non magna mauris, feugiat montes, porttitor eget nulla id id.

  • Lorem ipsum dolor sit amet, consectetur adipiscing elit.
  • Netus vestibulum dignissim scelerisque vitae.
  • Porttitor nibh est vulputate vitae sem vitae.
  • Amet tellus nisl risus lorem vulputate velit eget.
Vet candidates & ask for past references before hiring

Lorem ipsum dolor sit amet, consectetur adipiscing elit ut suspendisse convallis enim tincidunt nunc condimentum facilisi accumsan tempor donec dolor malesuada vestibulum in sed sed morbi accumsan tristique turpis vivamus non velit euismod.

“Lorem ipsum dolor sit amet, consectetur adipiscing elit nunc gravida purus urna, ipsum eu morbi in enim”
Once you hire them, give them access for all tools & resources for success

Lorem ipsum dolor sit amet, consectetur adipiscing elit ut suspendisse convallis enim tincidunt nunc condimentum facilisi accumsan tempor donec dolor malesuada vestibulum in sed sed morbi accumsan tristique turpis vivamus non velit euismod.

Igen népszerű a BDD - Behaviour Driven Development. Jellemzően azt gondolják, hogy a BDD egy tesztautomatizálási módszer, valójában nem teljesen az, sőt...

Sok a félreértés körülötte, ebből fakadóan gyorsan el lehet veszni egy BDD bevezetésben.

A BDD valójában nem is tesztelőknek készült. Kitalálója Dan North. Dan kereste az a megfelelő módszert, amivel a üzlet, fejlesztő és a tesztelő (továbbiakban hívjuk Csapatnak) jobban meg tudja érteni, hogy mit kell fejleszteni.

A BDD alapvetően 2 fázisból áll:

  1. Példák létrehozása, hogyan fogalmazunk meg egyszerűen, mindenki számára érthetően a rendszer tervezett működését (ami egyben a tesztesetek alapjai is lehet)
  2. Hogyan formalizáljuk a megírt példákat, hogy az könnyen automatizálható tesztesetek legyenek

Jellemző, hogy ez utóbbit értik a BDD alatt, amitől viszont esélyes, hogy nem megfelelő lesz a módszer alkalmazása.

Példák létrehozása, cél a közös megértés

Első körben a csapatnak össze kell gyűjtenie azokat az tipikus használati példákat, amelyek a legjellemzőbbek:

  • A rendszert leginkább leíró használati példákat tartalmazza
  • A megfogalmazás mindenki számára egyértelmű
  • Konkrét adatokat tartalmaz

Példa: Sütemény rendelő web oldal tipikus használata:

Torta megrendelés feladása

Példa 1. Tilda néni egy szép tortát szeretne rendelni az unokája születésnapjára, ehhez

  • Az oldalon kiválasztja a 12 szeletes gesztenye tortát
  • Kér kiegészítőket: 1 óriási csillagszórót
  • Kiválasztja a szállítási dátumot: október 26, és jóváhagyja
  • Bankkártyával kifizetésre kerül 25€
  • Tilda néni kap egy visszaigazolást emailben

Példa 2. Tilda néni kénytelen módosítani a szállítási időpontot, (mert a család átszervezte a születésnapot)

A szállítás előtt 2 nappal még lehet módosítani !

  • Tilda néni módosítja az időpontot október 29-re
  • Tilda néni kap egy visszaigazolást emailben
  • Mit rendelt, mennyit fizetett, mikor szállítják a tortát

Figyelem: a példákat nem kell Gherkin szintaxisban leírni, az majd a formalizálás része lesz!

A példák összegyűjtése segíti a Csapat közös megértését! Nem kell minden példát összegyűjteni, csak azokat, amelyek jól leírják a rendszer tipikus működését.

Ezek a példák egyben az alapvető tesztesetek illetve elfogadási feltételek (Acceptance Criteria) is.

Gherkin forma:

  • 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

Formalizálás = automatizálás

A példák összeállítása után jöhet a formalizálás. Gherkin formába át kell írni a példákat az automatizáláshoz. Fontos, hogy a fejlesztővel közösen kell összerakni a formalizált példákat, mert a BDD tesztek mögé már programrészek hívását kell beilleszteni, azaz alapvető, hogy a kialakított Gherkin mondatok alkalmazkodjanak a programkód struktúrájához, ezért a Gherkin mondatok eltér(het)nek a Példában megfogalmazottól.

A Gherkin formában megadott tesztesetek már futtathatók automatizálva. Jellemzően a service tesztek kialakítására szolgál, kevésbé javalt UI tesztek írására a BDD!

Az igazság…

Tegyük tisztába! A BDD egy specifikációs módszertan, ami segít a közös nyelv megteremtésében és másodsorban jelent automatizálási lehetőséget. Az első nélkül a második nem működik!

Amire érdemes figyelni a BDD használata során:

  • Úgy tekintsünk rá, hogy a BDD a specifikációt támogató módszer és nem tesztautomatizálás!
  • Válasszuk külön a példák létrehozását illetve a formalizálást (Gherkin szintaxisba átírás)!
  • A BDD a tesztautomatizálásban segít, de nem váltja ki a teljes tesztautomatizálást (lásd: tesztautomatizálási piramis: UI tesztek - service tesztek - unit tesztek)

Amit kerüljünk el

A BDD alkalmazásnál érdemes az alábbiakra fgyelni:

1. Nem biztos, hogy jó az, ha az üzlettől már eleve Gherkin formában várjuk a specifikációt:

  • az üzlet számára sem feltétlenül komfortos Gherkin nyelven történő írás
  • esélyes, hogy rosszul fogják alkalmazni
  • a fejlesztők nehezen fogják átkódolni

2. A tipikus példákat automatizáljuk (=regressziós tesztek), különben túlburjánzó automatizált tesztjeink lesznek

3. Ne UI tesztekre használjuk, hanem a gyorsan végrehajtható, kevésbé sérülékeny service tesztekre

… és akkor miért is Behaviour Driven?

Mert a BDD-vel a legjellemzőbb programhasználati viselkedést írhatjuk le, ami nagyban hozzájárul ahhoz, hogy a Csapat tagjai értsék, milyen alkalmazást kell létrehozni, mit kell tesztelni.

További infók, forrás: https://dannorth.net/introducing-bdd/

Sep 11, 2023

A BDD csapdájában

Jellemzően azt gondolják, hogy a BDD egy tesztautomatizálási módszer, valójában nem teljesen az, sőt...

A BDD csapdájában

Interview multiple candidates

Lorem ipsum dolor sit amet, consectetur adipiscing elit proin mi pellentesque  lorem turpis feugiat non sed sed sed aliquam lectus sodales gravida turpis maassa odio faucibus accumsan turpis nulla tellus purus ut   cursus lorem  in pellentesque risus turpis eget quam eu nunc sed diam.

Search for the right experience

Lorem ipsum dolor sit amet, consectetur adipiscing elit proin mi pellentesque  lorem turpis feugiat non sed sed sed aliquam lectus sodales gravida turpis maassa odio.

  1. Lorem ipsum dolor sit amet, consectetur adipiscing elit.
  2. Porttitor nibh est vulputate vitae sem vitae.
  3. Netus vestibulum dignissim scelerisque vitae.
  4. Amet tellus nisl risus lorem vulputate velit eget.

Ask for past work examples & results

Lorem ipsum dolor sit amet, consectetur adipiscing elit consectetur in proin mattis enim posuere maecenas non magna mauris, feugiat montes, porttitor eget nulla id id.

  • Lorem ipsum dolor sit amet, consectetur adipiscing elit.
  • Netus vestibulum dignissim scelerisque vitae.
  • Porttitor nibh est vulputate vitae sem vitae.
  • Amet tellus nisl risus lorem vulputate velit eget.
Vet candidates & ask for past references before hiring

Lorem ipsum dolor sit amet, consectetur adipiscing elit ut suspendisse convallis enim tincidunt nunc condimentum facilisi accumsan tempor donec dolor malesuada vestibulum in sed sed morbi accumsan tristique turpis vivamus non velit euismod.

“Lorem ipsum dolor sit amet, consectetur adipiscing elit nunc gravida purus urna, ipsum eu morbi in enim”
Once you hire them, give them access for all tools & resources for success

Lorem ipsum dolor sit amet, consectetur adipiscing elit ut suspendisse convallis enim tincidunt nunc condimentum facilisi accumsan tempor donec dolor malesuada vestibulum in sed sed morbi accumsan tristique turpis vivamus non velit euismod.

Igen népszerű a BDD - Behaviour Driven Development. Jellemzően azt gondolják, hogy a BDD egy tesztautomatizálási módszer, valójában nem teljesen az, sőt...

Sok a félreértés körülötte, ebből fakadóan gyorsan el lehet veszni egy BDD bevezetésben.

A BDD valójában nem is tesztelőknek készült. Kitalálója Dan North. Dan kereste az a megfelelő módszert, amivel a üzlet, fejlesztő és a tesztelő (továbbiakban hívjuk Csapatnak) jobban meg tudja érteni, hogy mit kell fejleszteni.

A BDD alapvetően 2 fázisból áll:

  1. Példák létrehozása, hogyan fogalmazunk meg egyszerűen, mindenki számára érthetően a rendszer tervezett működését (ami egyben a tesztesetek alapjai is lehet)
  2. Hogyan formalizáljuk a megírt példákat, hogy az könnyen automatizálható tesztesetek legyenek

Jellemző, hogy ez utóbbit értik a BDD alatt, amitől viszont esélyes, hogy nem megfelelő lesz a módszer alkalmazása.

Példák létrehozása, cél a közös megértés

Első körben a csapatnak össze kell gyűjtenie azokat az tipikus használati példákat, amelyek a legjellemzőbbek:

  • A rendszert leginkább leíró használati példákat tartalmazza
  • A megfogalmazás mindenki számára egyértelmű
  • Konkrét adatokat tartalmaz

Példa: Sütemény rendelő web oldal tipikus használata:

Torta megrendelés feladása

Példa 1. Tilda néni egy szép tortát szeretne rendelni az unokája születésnapjára, ehhez

  • Az oldalon kiválasztja a 12 szeletes gesztenye tortát
  • Kér kiegészítőket: 1 óriási csillagszórót
  • Kiválasztja a szállítási dátumot: október 26, és jóváhagyja
  • Bankkártyával kifizetésre kerül 25€
  • Tilda néni kap egy visszaigazolást emailben

Példa 2. Tilda néni kénytelen módosítani a szállítási időpontot, (mert a család átszervezte a születésnapot)

A szállítás előtt 2 nappal még lehet módosítani !

  • Tilda néni módosítja az időpontot október 29-re
  • Tilda néni kap egy visszaigazolást emailben
  • Mit rendelt, mennyit fizetett, mikor szállítják a tortát

Figyelem: a példákat nem kell Gherkin szintaxisban leírni, az majd a formalizálás része lesz!

A példák összegyűjtése segíti a Csapat közös megértését! Nem kell minden példát összegyűjteni, csak azokat, amelyek jól leírják a rendszer tipikus működését.

Ezek a példák egyben az alapvető tesztesetek illetve elfogadási feltételek (Acceptance Criteria) is.

Gherkin forma:

  • 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

Formalizálás = automatizálás

A példák összeállítása után jöhet a formalizálás. Gherkin formába át kell írni a példákat az automatizáláshoz. Fontos, hogy a fejlesztővel közösen kell összerakni a formalizált példákat, mert a BDD tesztek mögé már programrészek hívását kell beilleszteni, azaz alapvető, hogy a kialakított Gherkin mondatok alkalmazkodjanak a programkód struktúrájához, ezért a Gherkin mondatok eltér(het)nek a Példában megfogalmazottól.

A Gherkin formában megadott tesztesetek már futtathatók automatizálva. Jellemzően a service tesztek kialakítására szolgál, kevésbé javalt UI tesztek írására a BDD!

Az igazság…

Tegyük tisztába! A BDD egy specifikációs módszertan, ami segít a közös nyelv megteremtésében és másodsorban jelent automatizálási lehetőséget. Az első nélkül a második nem működik!

Amire érdemes figyelni a BDD használata során:

  • Úgy tekintsünk rá, hogy a BDD a specifikációt támogató módszer és nem tesztautomatizálás!
  • Válasszuk külön a példák létrehozását illetve a formalizálást (Gherkin szintaxisba átírás)!
  • A BDD a tesztautomatizálásban segít, de nem váltja ki a teljes tesztautomatizálást (lásd: tesztautomatizálási piramis: UI tesztek - service tesztek - unit tesztek)

Amit kerüljünk el

A BDD alkalmazásnál érdemes az alábbiakra fgyelni:

1. Nem biztos, hogy jó az, ha az üzlettől már eleve Gherkin formában várjuk a specifikációt:

  • az üzlet számára sem feltétlenül komfortos Gherkin nyelven történő írás
  • esélyes, hogy rosszul fogják alkalmazni
  • a fejlesztők nehezen fogják átkódolni

2. A tipikus példákat automatizáljuk (=regressziós tesztek), különben túlburjánzó automatizált tesztjeink lesznek

3. Ne UI tesztekre használjuk, hanem a gyorsan végrehajtható, kevésbé sérülékeny service tesztekre

… és akkor miért is Behaviour Driven?

Mert a BDD-vel a legjellemzőbb programhasználati viselkedést írhatjuk le, ami nagyban hozzájárul ahhoz, hogy a Csapat tagjai értsék, milyen alkalmazást kell létrehozni, mit kell tesztelni.

További infók, forrás: https://dannorth.net/introducing-bdd/