Elfogadási teszt által vezérelt fejlesztés
| Ez a szócikk nem tünteti fel a független forrásokat, amelyeket felhasználtak a készítése során. Emiatt nem tudjuk közvetlenül ellenőrizni, hogy a szócikkben szereplő állítások helytállóak-e. Segíts megbízható forrásokat találni az állításokhoz! Lásd még: A Wikipédia nem az első közlés helye. |
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 szerkeszté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 szerkeszté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 szerkesztés
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 szerkesztés
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 szerkesztés
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 szerkesztés
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önyvek | |
|---|---|
| Cím | Kölcsönzés alatt |
| A Pál utcai fiúk | Nem |
- 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űvelet | |||
|---|---|---|---|
| Felhasználó | Áts Feri | Kölcsönzés alatt | A Pál utcai fiúk |
Ezután – Then:
- A könyv megjelölése kikölcsönzöttként
| Könyvek | ||
|---|---|---|
| Cím | Kölcsönzés alatt | Felhasználó |
| A Pál utcai fiúk | Igen | Áts Feri |
Vizsgálati vizsgálat szerkesztés
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 szerkesztés
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önyvek | ||
|---|---|---|
| Cím | Kikölcsönzés alatt | Felhasználó |
| A Pál utcai fiúk | Igen | Áts Feri |
| Az ember tragédiája | Nem |
| Felhasználók |
|---|
| Név |
| Áts Feri |
Mikor – When:
- A felhasználó kivesz egy másik könyvet is
| Művelet | |||
|---|---|---|---|
| Felhasználó | Áts Feri | Kikölcsönzés alatt | Az ember tragédiája |
Ezután – Then:
- Hiba üzenet
| Hiba történt |
|---|
| A hiba leírása |
| Üzleti szabályok megsértése |
Projektelfogadási tesztek szerkesztés
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".