Az elfogadási teszt által vezérelt fejlesztés (Acceptance test–driven development – ATDD) az üzleti ügyfelek, a fejlesztők és a tesztelők közötti kommunikáción alapuló fejlesztési módszertan. Az ATDD számos olyan gyakorlatot foglal magában, mint a "specifikáció a példában" (specification by example – SBE), a viselkedésvezérelt fejlesztés (behavior-driven development – BDD), a példavezérelt fejlesztés (example-driven development – EDD) és a támogatásvezérelt fejlesztés, amelyet történetteszt-alapú fejlesztésnek (story test–driven development – SDD) is neveznek. Mindezek a folyamatok segítik a fejlesztőket és a tesztelőket abban, hogy a megvalósítás előtt megértsék az ügyfél igényeit, és lehetővé tegyék az ügyfelek számára a nyílt beszélgetést.
Az ATDD szorosan kapcsolódik a tesztvezérelt fejlesztéshez (TDD). A kettő a fejlesztő-tesztelő-üzleti ügyfél-együttműködésre helyezett hangsúlyban tér el. Az ATDD magában foglalja az elfogadási teszteket, de kiemeli elfogadási tesztek írását, mielőtt a fejlesztők megkezdik a kódolást.
Áttekintés Az elfogadási tesztek a felhasználó szemszögéből nézve – a rendszer külső nézete. Külsőleg látható hatásokat vizsgálnak, például egy adott bemenethez adott rendszer helyes kimenetét. Az elfogadási tesztek ellenőrizhetik, hogy valami állapota hogyan változik, például egy olyan megrendelés, amely a "fizetett" és a "szállított" között változik. Más rendszerek, például megosztott adatbázisok vagy webszolgáltatások felületeivel való interakciókat is ellenőrizhetik. Általában ezek a végrehajtása független, bár automatizálni ezeket nem lehet.
Létrehozás Elfogadási tesztek a követelmények elemzése és kódolás megkezdése előtt jönnek létre. Ezek közösen fejleszthetők a követelmény-kérelmező (terméktulajdonos, üzleti elemző, ügyfél-képviselő stb.), fejlesztő és tesztelő szerint. A fejlesztők az elfogadási tesztek segítségével valósítják meg a rendszert. A sikertelen tesztek gyors visszajelzést adnak arról, hogy a követelmények nem teljesülnek. A tesztek az üzleti tartomány feltételeiben vannak megadva. A kifejezések ezután az ügyfelek, a fejlesztők és a tesztelők között megosztott, mindenütt jelen lévő nyelvet alkotnak. A tesztek és a követelmények összefüggenek egymással. Előfordulhat, hogy a teszt hiányára vonatkozó követelményt nem megfelelően tudják végrehajtani. A követelményre nem hivatkozó teszt szükségtelen. A megvalósítás megkezdése után kifejlesztett elfogadási teszt, új követelményt jelent.
Tesztelési stratégia Az elfogadási tesztek egy átfogó vizsgálati stratégia részét képezik. Ezek azok az ügyfél tesztek, amelyek a rendszer üzleti szándékát mutatják be. Az alkatrész-tesztek, egy építész által kifejlesztett, műszaki elfogadási tesztek, amelyek meghatározzák a nagy modulok viselkedését. Az egység-teszteket a fejlesztő hozta létre, hogy könnyen karbantartható kódot készítsen. Ezek gyakran elfogadási- és egység vizsgálatokból származnak. A kereszt-funkcionális tesztelés magában foglalja a használhatósági tesztelést, a feltáró tesztelést, valamint az ingatlantesztelést (méretezés és biztonság).
Elfogadási kritériumok és tesztek Az elfogadási kritériumok annak leírásai, hogy mit ellenőriz egy teszt. Mivel a követelmény, mint "A felhasználó azt akarja, hogy nézd meg a könyvet a könyvtárból", egy elfogadási kritérium lehet, "Ellenőrizze a könyv ki van véve jelölést". Az e követelményre vonatkozó elfogadási vizsgálat megadja a részleteket, hogy a vizsgálat minden alkalommal azonos hatással fusson.
Tesztformátum Az átvételi vizsgálatok általában ezt a formanyomtatványt követik:
Adott – Given (beállítás)
A rendszer megadott állapota.
Mikor – When (trigger)
Művelet vagy esemény történik.
Ezután – Then (ellenőrzés)
A rendszer állapota megváltozott, vagy kimenet készült.
Az is lehetséges, hogy megadunk egy nyilatkozatot a kezdő értéket és egy ÉS-t (AND) bármely szakasz alatt (Adott, Mikor, Ezután).
A példakövetelmény esetében a lépések a következőképpen sorolhatók fel:Given A könyv nincs kivéve And A felhasználó regisztrálva van a rendszerben When A felszanáló kiválasztja az adott könyvet Then A könyv megjelölése kivettként
Teljes teszt Az előző lépések nem tartalmaznak konkrét példaadatokat, így a program hozzáadja a teszt befejezéséhez:
Adott – Given:
A könyv nincs kivéve
KönyvekCímKölcsönzés alattA Pál utcai fiúkNem
A felhasználó regisztrálva van a rendszerben
FelhasználóNévÁts Feri Mikor – When:
A felhasználó kiválasztja az adott könyvet
MűveletFelhasználóÁts FeriKölcsönzés alattA Pál utcai fiúk Ezután – Then:
A könyv megjelölése kikölcsönzöttként
KönyvekCímKölcsönzés alattFelhasználóA Pál utcai fiúkIgenÁts Feri
Vizsgálati vizsgálat A vizsgálat konkrét adatokkal való vizsgálata általában sok kérdést vet fel. A minta esetében ezek a következők lehetnek:
Mi van, ha a könyv már ki van véve? Mi van, ha a könyv nem létezik? Mi a teendő, ha a felhasználó nincs regisztrálva a rendszerben? Van olyan dátum, amire a könyvet vissza kell hozni? Hány könyvet vehet ki egy felhasználó?
Ezek a kérdések segítenek megvilágítani a hiányzó vagy kétértelmű követelményeket. További részleteket, például a határidőt hozzá lehet adni a várt eredményhez. Más elfogadási tesztek ellenőrizhetik, hogy a feltételek, például a már kivett könyv kivételének megkísérlése a várt hibát eredményezik e.
Egy másik teszt példa Tegyük fel, hogy az üzleti ügyfél olyan üzleti szabályt szeretne, amelyben a felhasználó egyszerre csak egy könyvet vehet ki. A következő vizsgálat azt bizonyítja, hogy:
Forgatókönyv: Az üzleti szabályzat betartásának ellenőrzése
Adott – Given:
Egy kikölcsönzött könyv
KönyvekCímKikölcsönzés alattFelhasználóA Pál utcai fiúkIgenÁts FeriAz ember tragédiájaNem FelhasználókNévÁts Feri Mikor – When:
A felhasználó kivesz egy másik könyvet is
MűveletFelhasználóÁts FeriKikölcsönzés alattAz ember tragédiája Ezután – Then:
Hiba üzenet
Hiba történtA hiba leírásaÜzleti szabályok megsértése
Projektelfogadási tesztek A követelmények elfogadási tesztjein kívül az elfogadási tesztek a projekt egészén is használhatók. Ha például ez a követelmény egy könyvtári csekkfüzet projekt része volt, akkor az egész projektre lehetnek elfogadási tesztek. Ezeket gyakran SMART-célkitűzéseknek nevezik . Egy példa teszt "Amikor az új könyvtári rendszer éles, a felhasználók képesek lesznek, hogy ellenőrizzék a könyveket, háromszor olyan gyorsan, mint ma".
Kapcsolódó szócikk Robot Framework
További információk Example of automation frameworks
Kategória:Szoftverfejlesztés