Ugrás a tartalomhoz

Szerkesztő:BubblyJubbly/Elfogadási teszt

A Wikipédiából, a szabad enciklopédiából
Egy repülőgép katapultjának elfogadási tesztje
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 feketedoboz-tesztet, 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.[1]

A szoftvertesztelésben, az ISTQB így határozza meg az elfogadási tesztet:

„Hivatalos tesztelés a felhasználói igényekre, követelményekre és üzleti folyamatokra vonatkozóan annak megállapítására, hogy a rendszer megfelel-e az elfogadási kritériumoknak [2] , és hogy a felhasználó, az ügyfelek vagy más jogosult személyek eldönthessék, elfogadják-e a rendszert.”

– Standard Glossary of Terms used in Software Testing[3]:2

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.[4]

A füst teszt használható elfogadási tesztként, mielőtt bevezetjük a szoftver felépítését a fő tesztelési folyamatba.

 

Áttekintés

[szerkeszté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. [5] 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égellenő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.[6]

Folyamat

[szerkesztés]

Előfordulhat, hogy az elfogadási tesztcsomagot többször kell végrehajtani, mivel megtörténhet, hogy az összes tesztesetet nem lehet egyetlen teszt iteráción belül végrehajtani. [7]

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. [7] 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

[szerkesztés]

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.[8] 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.[9]

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.[10]

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ára; 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 teszt forgatókönyvek alapján kell végrehajtani.  Teszt forgató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 rendszer-specifikus részleteken legyen, illetve nem használ "kattintásonkénti" teszt lépéseket, hogy eltérés lehessen a felhasználók viselkedésében. A teszt forgató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.[11][12]

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

[szerkesztés]

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

[szerkesztés]

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.[13]

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.[14]

Az elfogadási teszt típusai

[szerkesztés]

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.[15]
Operaí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.[16]
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ás-tesztelési keretek listája

[szerkesztés]

Lásd még

[szerkesztés]

Hivatkozások

[szerkesztés]

 

  1. ↑ Black, Rex. Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing. Hoboken, NJ: Wiley (2009. augusztus 1.). ISBN 0-470-40415-9 
  2. ↑ acceptance criteria. Innolution, LLC, 2019. június 10.
  3. ↑ Standard Glossary of Terms used in Software Testing, Version 3.2: All Terms (PDF). ISTQB. (Hozzáférés: 2020. november 23.)
  4. ↑ ISO/IEC/IEEE International Standard - Systems and software engineering. ISO/IEC/IEEE, vol., no., pp.1–418. o. (2010) 
  5. ↑ ISO/IEC/IEEE 29119-1-2013 Software and Systems Engineering - Software Testing - Part 1- Concepts and Definitions. ISO (2013. november 29.). Hozzáférés ideje: 2014. október 14. 
  6. ↑ ISO/IEC/IEEE DIS 29119-4 Software and Systems Engineering - Software Testing - Part 4- Test Techniques. ISO (2013. november 29.). Hozzáférés ideje: 2014. október 14. 
  7. ↑ a b ISO/IEC/IEEE 29119-2-2013 Software and Systems Engineering - Software Testing - Part 2- Test Processes. ISO (2013. november 29.). Hozzáférés ideje: 2014. május 21. 
  8. ↑ Cimperman, Rob. UAT Defined: A Guide to Practical User Acceptance Testing. Pearson Education, Chapter 2. o. (2006). ISBN 9780132702621 
  9. ↑ Goethem, Brian. User acceptance testing : a step-by-step guide. BCS Learning & Development Limited (2013). ISBN 9781780171678 
  10. ↑ Pusuluri, Nageshwar Rao. Software Testing Concepts And Tools. Dreamtech Press, 62. o. (2006). ISBN 9788177227123 
  11. ↑ Factory Acceptance Test (FAT). Tuv.com. [2013. február 4-i dátummal az eredetiből archiválva]. (Hozzáférés: 2012. szeptember 18.)
  12. ↑ Factory Acceptance Test. Inspection-for-industry.com. (Hozzáférés: 2012. szeptember 18.)
  13. ↑ Introduction to Acceptance/Customer Tests as Requirements Artifacts. agilemodeling.com. Agile Modeling. (Hozzáférés: 2013. december 9.)
  14. ↑ Wells: Acceptance Tests. Extremeprogramming.org. (Hozzáférés: 2011. szeptember 20.)
  15. ↑ Prasad. „The Difference Between a FAT and a SAT”, Kneat.com, 2012. március 29. (Hozzáférés: 2016. július 27.) 
  16. ↑ ISTQB Standard glossary of terms used in Software Testing. (Hozzáférés: 2019. március 15.)

További irodalom

[szerkesztés]
  • Hambling, Brian. User Acceptance Testing: A Step by Step Guide. Swindon: BCS Learning and Development Ltd (2013). ISBN 978-1-78017-167-8 

Külső linkek

[szerkesztés]

[[Kategória:Agilis szoftverfejlesztés]] [[Kategória:Szoftvertesztelés]]

A lap eredeti címe: „https://hu.wikipedia.org/w/index.php?title=Szerkesztő:BubblyJubbly/Elfogadási_teszt&oldid=26219020”