jobbra|bélyegkép| Egy repülőgép katapultjának elfogadási tesztje jobbra|bélyegkép| A James Webb űrtávcső elsődleges tükrei közül hatot elfogadási tesztre készítenek fel A mérnöki szakterületen és annak különböző alterületein az elfogadási teszt egy olyan teszt, amelyet annak megállapítására használnak, hogy a specifikáció vagy a szerződés követelményei teljesülnek-e. Ez magában foglalhat kémiai vizsgálatokat, fizikai vizsgálatokat vagy teljesítményvizsgálatokat.
A rendszertechnikában ez magában foglalhatja a feketedoboztesztet, melyet a rendszeren végeznek el (például: egy szoftver, sok gyártott mechanikus alkatrész vagy vegyi termék tétele) a szállítás előtt.
A szoftvertesztelésben az ISTQB így határozza meg az elfogadási tesztet:
Az elfogadás tesztelése más néven felhasználói elfogadási teszt (UAT), végfelhasználói tesztelés, operatív elfogadási teszt (OAT), elfogadási tesztvezérelt fejlesztés (ATDD) vagy terepi (elfogadás) teszt. Az elfogadási kritériumok azok a kritériumok, amelyeknek egy rendszernek vagy alkatrésznek meg kell felelnie ahhoz, hogy elfogadja a felhasználó, az ügyfél vagy más felhatalmazott szervezet.
A füstteszt használható elfogadási tesztként, mielőtt bevezetjük a szoftver felépítését a fő tesztelési folyamatba.
Áttekintés A tesztelés egy vagy több tesztelt elem tulajdonságainak felfedezésének és/vagy értékelésére végzett tevékenységek összessége. Minden egyes teszt, amelyet tesztesetnek neveznek, előre meghatározott vizsgálati tevékenységeket hajt végre, amelyeket a tesztelem végrehajtásának a teszt célkitűzéseinek teljesítése érdekében fejlesztettek ki; beleértve a helyes megvalósítást, a hibák azonosítását, a minőség-ellenőrzést és más értékes részleteket. A tesztkörnyezetet általában úgy tervezik, hogy azonos legyen, vagy a lehető legközelebb álljon a várható gyártási környezettel. Ez magában foglal minden olyan szoftvert, hardvert, szoftvert, firmware-t, eljárásokat és/vagy dokumentációt, amelyeket a szoftver tesztelésére szántak vagy használtak.
Az UAT és OAT tesztesetek ideális esetben üzleti ügyfelekkel, üzleti elemzőkkel, tesztelőkkel és fejlesztőkkel együttműködésben származnak. Rendkívül fontos, hogy ezek a tesztek üzleti logikai teszteket, valamint működési környezeti feltételeket is tartalmazzanak. Az üzleti ügyfelek (terméktulajdonosok) ezek a tesztek elsődleges érdekelt személyei. Amint a tesztfeltételek sikeresen teljesítik elfogadási kritériumaikat, az érintettek megnyugodhatnak, hogy a fejlesztés a megfelelő irányba halad.
A felhasználói elfogadási teszt (UAT) kritériumait (az agilis szoftverfejlesztésben) általában üzleti ügyfelek hozzák létre, és üzleti domain nyelven fejezik ki. Ezek magas szintű tesztek annak ellenőrzésére, hogy egy sprint/iteráció során egy „eljátszott” felhasználói történet vagy történetek teljesek-e. Az operatív elfogadási teszt (OAT) kritériumait (attól függetlenül, hogy agilis, iteratív vagy szekvenciális fejlesztést alkalmaznak) funkcionális és nem funkcionális követelmények szerint határozzák meg; ezzel lefedve a funkcionális stabilitás, hordozhatóság és megbízhatóság kulcsfontosságú jellemzőit.
Folyamat Előfordulhat, hogy az elfogadási tesztcsomagot többször kell végrehajtani, mivel megtörténhet, hogy az összes tesztesetet nem lehet egyetlen tesztiteráción belül végrehajtani.
Az elfogadó tesztcsomag előre definiált elfogadási teszteljárások segítségével futtatja a tesztelőket, hogy mely adatokat kell használni, a lépésről-lépésre követendő folyamatokat és a végrehajtás után várható eredményt. A tényleges eredményeket megtartjuk a várt eredményekkel való összehasonlítás céljából. Ha a tényleges eredmények megegyeznek az egyes tesztesetek várható eredményeivel, akkor azt mondják, hogy a tesztesetek sikeresek. Ha a nem átmenő tesztesetek száma nem ütközik a projekt előre meghatározott küszöbértékével, akkor a tesztcsomag állítólag sikeres. Ha mégis megtörténik, akkor a rendszert a szponzor és a gyártó között előzetesen megállapodott feltételek mellett vagy elutasíthatják, vagy elfogadhatják.
A sikeres teszt végrehajtásának várható eredménye:
a teszteseteket előre meghatározott adatok felhasználásával hajtják végre a tényleges eredményeket rögzítik a tényleges és a várható eredményeket összehasonlítják, és a teszt eredményeit meghatározzuk.
A cél annak biztosítása, hogy a kifejlesztett termék megfelel mind a funkcionális, mind a nem funkcionális követelményeknek. Az elfogadási teszt elvégzésének célja, hogy miután befejeződött, és amennyiben az elfogadási kritériumok teljesülnek, a szponzorok várhatóan aláírják a termékfejlesztést/fejlesztést, amely megfelel a meghatározott követelményeknek (melyben korábban az üzleti vállalkozás és a termék szolgáltatója/fejlesztője megállapodott).
Felhasználói elfogadási teszt A felhasználói elfogadási teszt (UAT) abból áll, hogy ellenőrizzük, hogy a megoldás működik-e a felhasználó számára. Ez nem a rendszer tesztelése (hanem annak biztosítása, hogy a szoftver ne omoljon össze és megfeleljen a dokumentált követelményeknek) és inkább annak ellenőrzése, hogy a megoldás működik-e a felhasználó számára (más megfogalmazással teszteli, hogy a felhasználó elfogadja-e a megoldást); a szoftvergyártók ezt gyakran "béta tesztelésnek" nevezik.
Ezt a tesztelést egy tárgyi szakértőnek (SME) kell elvégeznie, lehetőleg a tesztelt megoldás tulajdonosának vagy megrendelőjének, és a megállapítások összegzését meg kell adnia, hogy megerősítést nyerjen a kipróbálás vagy felülvizsgálat után. A szoftverfejlesztésben az UAT, mint a projekt egyik utolsó szakasza, gyakran előfordul azelőtt, hogy az ügyfél vagy a vásárló elfogadná az új rendszert. A rendszer használói olyan teszteket végeznek, melyek valós szituációban is előfordulhatnak.
Fontos, hogy a tesztelőnek adott anyagok hasonlóak legyenek a végfelhasználó számára rendelkezésére álló anyagokkal. A tesztelőknek olyan valós szituációkat kell adni, mint például a három leggyakoribb vagy legnehezebb feladat, amelyet az általuk képviselt felhasználók elvégeznek.
Az UAT a szükséges üzleti funkcionalitás és a rendszer megfelelő működésének végső hitelesítőjeként működik, amely valós feltételeket emulál a fizető ügyfél vagy egy konkrét nagy ügyfél nevében. Ha a szoftver a kértnek megfelelően és minden probléma nélkül működik az alap használata során, akkor ésszerűen extrapolálhatjuk a termelésen az ugyanolyan szintű stabilitását.
A felhasználói tesztek, amelyeket általában az ügyfelek vagy a végfelhasználók végeznek el, alapvetően nem az egyszerű kozmetikai problémák azonosítására koncentrálnak, mint például a helyesírási hibákra, a showstopper hibákra, ilyen például a szoftver összeomlás; a tesztelők és fejlesztők azonosítják és kijavítják ezeket a problémákat a korábbi egységtesztelési, integrációs tesztelési és rendszertesztelési fázisok során.
Az UAT-t tesztforgatókönyvek alapján kell végrehajtani. Tesztforgatókönyvek általában abban különböznek a rendszer vagy a funkcionális teszt esettől, hogy a "játékos" vagy "felhasználó" utazást képviselnek. A tesztforgatókönyv tág jellege biztosítja, hogy a hangsúly az utazáson, és ne a műszaki vagy a rendszerspecifikus részleteken legyen, illetve nem használ "kattintásonkénti" tesztlépéseket, hogy eltérés lehessen a felhasználók viselkedésében. A tesztforgatókönyvek logikai "napokra" bonthatók, amelyek általában ahol a szereplő (játékos/ügyfél/operátor) vagy a rendszer (backoffice, kezelőfelület) változik.
Az iparban a közös UAT a gyári elfogadási teszt (FAT). Ezt a tesztet a berendezés telepítése előtt kell elvégezni. A tesztelők többnyire nemcsak azt ellenőrzik, hogy a berendezés megfelel-e az előírásoknak, hanem azt is, hogy teljesen működőképesek-e. A FAT általában magában foglalja a teljesség ellenőrzését, a szerződéses követelményekhez való verifikációt, a funkcionalitás igazolását (akár szimulációval, akár hagyományos funkcióvizsgálattal) és egy utolsó ellenőrzést.
E tesztek eredményei bizalmat adnak az ügyfeleknek abban, hogy a rendszer hogyan fog teljesíteni a termelésben. A rendszer elfogadásának jogi vagy szerződéses követelményei is lehetnek.
Operatív elfogadási teszt Az operatív elfogadási teszt (OAT) egy termék, szolgáltatás vagy rendszer működési készenlétének (előzetes kiadásának) elvégzésére szolgál a minőségirányítási rendszer részeként. Az OAT a nem funkcionális szoftverek tesztelésének elterjedt típusa, amelyet főleg szoftverfejlesztési és szoftverfenntartási projektekben használnak. Ez a fajta teszt a támogatott rendszer működési felkészültségére és/vagy a termelési környezet részévé tételére összpontosít.
Elfogadási teszt extrém programozásban Az elfogadási tesztelés az agilis szoftverfejlesztési módszertanokban, különösen az extrém programozásban használt kifejezés, amely a felhasználói történet funkcionális tesztelésére utal, mely a megvalósítási szakaszban történik egy szoftverfejlesztő csapat által.
Az ügyfél megad eshetőségeket annak tesztelésére, hogy a felhasználói történet miként valósult meg megfelelően. Egy történetnek egy vagy több elfogadási tesztje lehet, attól függően, hogy mennyi szükséges a funkcionalitás biztosításához. Az elfogadási tesztek a feketedobozos rendszer tesztjei. Minden elfogadási teszt a rendszer várható eredményét képviseli. Az ügyfelek felelősek az elfogadási tesztek helyességének ellenőrzéséért és a tesztek eredményeinek áttekintéséért annak eldöntésének érdekében, hogy melyik sikertelen teszt a legfontosabb. Az elfogadási teszteket regressziós tesztként is használják a gyártás kiadása előtt. A felhasználói történet csak akkor tekinthető teljesnek, ha az sikeresen átment az elfogadási teszteken. Ez azt jelenti, hogy minden iterációhoz új elfogadási teszteket kell létrehozni, különben a fejlesztői csapat semmilyen előrelépésről nem tud beszámolni.
Az elfogadási teszt típusai Az elfogadási teszt tipikus típusai a következők
Felhasználói elfogadás tesztelése
Ez magában foglalhatja a gyári elfogadási tesztet (FAT), vagyis azt a tesztelést, amelyet egy eladó végez, mielőtt a terméket vagy a rendszert a rendeltetési helyére helyezik át, majd ezt követően a helyszíni elfogadási tesztjét (SAT) a felhasználók is elvégezhetik a helyszínen. Operatív elfogadási teszt Operatív készenléti tesztként is ismert, ez a rendszeren elvégzett ellenőrzésre vonatkozik, mellyel biztosítják, hogy a folyamatok és eljárások a rendszer használatát és karbantartását lehetővé tegyék. Ez magában foglalhatja a biztonsági létesítmények ellenőrzését, a katasztrófa utáni helyreállítási eljárásokat, a végfelhasználók számára szervezett képzést, a karbantartási és biztonsági eljárásokat. A szerződés és a szabályozás elfogadási tesztje A szerződés elfogadási tesztje során a rendszert a szerződés elfogadása előtt tesztelik a szerződésben dokumentált elfogadási kritériumok alapján. A szabályozás elfogadási tesztje során egy rendszert tesztelnek annak érdekében, hogy az megfeleljen a kormányzati, jogi és biztonsági előírásoknak.
Gyári elfogadási teszt Elfogadási teszt azon a helyen végzik el, ahol a terméket fejlesztették és elvégezték a szállítói szervezet alkalmazottai, annak megállapítására, hogy egy alkatrész vagy rendszer megfelel-e a követelményeknek, általában beleértve a hardvert és a szoftvert is.
Alfa és béta tesztelés Az alfa tesztelés a fejlesztők telephelyén történik, és magában foglalja az operációs rendszer belső személyzet általi tesztelését, mielőtt azt külső ügyfelek számára kiadnák. A béta tesztelés az ügyfelek helyszínein zajlik, és magában foglalja az ügyfelek egy csoportjának tesztelését, akik a rendszert saját helyükön használják és visszajelzést adnak, mielőtt a rendszert kiadják más ügyfeleknek. Ez utóbbit gyakran "terepi tesztnek" nevezik.
Az elfogadástesztelési keretek listája
Concordion, Specifikáció példával (SbE) keretrendszer Concordion.NET, .NET-ben történő elfogadási tesztelés Cucumber, a viselkedésvezérelt fejlesztés (BDD) elfogadási teszt keretrendszer