Mi a felhasználói elfogadás tesztelése (UAT): Teljes útmutató

Tudja meg, mi a felhasználói elfogadás tesztelése (UAT) , A definícióval, típusokkal, lépésekkel és példákkal együtt:

Az első számú szabályom, amikor megpróbálok megérteni egy új fogalmat, az az, hogy: a név mindig releváns lesz, és többnyire szó szerinti jelentése (a technikai kontextus).

Ha megtudja, mi ez, akkor kezdeti megértést kap róla, és segít abban, hogy elinduljak.

= > Kattintson ide a teljes tesztterv bemutató sorozatához

Tegyük próbára ezt a koncepciót.

= > Olvassa el az Acceptance Testing sorozat összes oktatóanyagát.

Mi a felhasználói elfogadás tesztelése?

Tudjuk, mi a tesztelés, az elfogadás jóváhagyást vagy megállapodást jelent. A szoftvertermékkel összefüggésben a felhasználó vagy a szoftver fogyasztója, vagy az a személy, aki azt kérte, hogy neki (kliensnek) építsék fel.

Tehát a szabályomat követve – a meghatározás :

A felhasználói elfogadás tesztelése (UAT), más néven béta vagy végfelhasználói tesztelés, a szoftver tesztelése a felhasználó vagy az ügyfél által annak meghatározása érdekében, hogy elfogadható-e vagy sem. Ez az utolsó teszt, amelyet a funkcionális, a rendszer- és a regressziós teszt befejezése után hajtanak végre.

A tesztelés fő célja a szoftver ellenőrzése az üzleti követelményeknek megfelelően. Ezt az érvényesítést a végfelhasználók végzik, akik ismerik az üzleti követelményeket.

Az UAT, az alfa és a béta tesztek az elfogadás tesztelésének különböző típusai.

Mivel a felhasználói elfogadási teszt az utolsó teszt, amelyet a szoftver életbe lépése előtt hajtanak végre, nyilván ez az az utolsó lehetőség az ügyfél számára, hogy tesztelje a szoftvert és megmérje, hogy alkalmas-e a célra.

Mikor hajtják végre?

Ez általában az utolsó lépés, mielőtt a termék életbe lépne vagy mielőtt a termék kiszállítását elfogadják. Ez a termék alapos tesztelése után történik (azaz a rendszer tesztelése után).

Ki végez UAT-t?

Felhasználók vagy kliens – Ez lehet valaki, aki terméket vásárol ( kereskedelmi szoftver esetén), vagy valaki, aki egy szoftvert egy szoftverszolgáltatón vagy a végfelhasználón keresztül testre szabott, ha a szoftvert idő előtt elérhetővé teszik számukra, és amikor visszajelzésüket kérik.

A csapat bétatesztelőkből állhat, vagy az ügyfélnek a szervezet minden csoportjából belül kell kiválasztania az UAT tagokat, hogy az egyes felhasználói szerepeket ennek megfelelően tesztelhessék.

A felhasználói elfogadás tesztelésének szükségessége

A fejlesztők és a funkcionális tesztelők olyan technikai szakemberek, akik a szoftvert a funkcionális specifikációkkal összhangban ellenőrzik. Értelmezésük szerint értelmezik a követelményeket, és fejlesztik / tesztelik a szoftvert (itt van a tartományi ismeretek fontossága).

Ez a szoftver a funkcionális specifikációknak megfelelően teljes, de vannak üzleti követelmények és folyamatok, csak a végfelhasználók által ismert kommunikáció hiányzik, vagy félreértelmezik őket.

Ez a teszt fontos szerepet játszik annak ellenőrzésében, hogy az üzleti követelmények teljesülnek-e vagy sem, mielőtt a szoftvert piaci használatra bocsátanák. Az élő adatok használata és a valós felhasználási esetek teszik ezt a tesztelést a kiadási ciklus fontos részévé.

Sok olyan vállalkozás, amely nagy veszteségeket szenvedett a kiadás utáni problémák miatt, tudja a sikeres felhasználói elfogadási teszt fontosságát. A hibák kijavításának kiadása a kiadás után sokszor nagyobb, mint azelőtt kijavítás.

Valóban szükség van az UAT-ra?

A rengeteg rendszer, integráció és regressziós teszt elvégzése után kíváncsi lehet ennek a tesztnek a szükségessége. Valójában ez a projekt legfontosabb fázisa, mivel ez az az idő, amikor a felhasználók, akik ténylegesen használni fogják a rendszert, érvényesítik a rendszert a rendeltetésének megfelelően.

Az UAT egy teszt szakasz, amely nagyban függ a végfelhasználók perspektívájától és a végfelhasználókat képviselő részleg tartományismeretétől.

Ami azt illeti, valóban hasznos lenne az üzleti csapatok számára, ha elég korán vettek részt a projektben, hogy elmondhassák véleményüket és hozzájárulásaikat, amelyek elősegítik a rendszer hatékony használatát a való életben.

Felhasználói elfogadás tesztelési folyamat

A folyamat megértésének legegyszerűbb módja, ha ezt egy önálló tesztelési projektnek gondoljuk – ami azt jelenti, hogy meglesz a terv, a tervezés és a kivitelezés fázisa.

Az alábbiakban bemutatjuk a tervezési szakasz előtti előfeltételeket kezdődik:

# 1) Gyűjtse össze a legfontosabb elfogadási feltételeket.

Egyszerűbben kifejezve, az elfogadási kritériumok a következők: A termék elfogadása előtt kiértékelésre kerülő cégek.

Ezeknek két típusa lehet:

(i) Alkalmazásfunkciók vagy Üzleti vonatkozású

Ideális esetben az összes kulcsfontosságú üzleti funkciót érvényesíteni kell, de a különféle okokból, beleértve az időt is, nem célszerű mindezt elvégezni. Ezért egy vagy két megbeszélés az ügyféllel vagy a felhasználókkal, akik részt vesznek ebben a tesztelésben, képet adhatnak arról, hogy mennyi tesztet kell bevonni és milyen szempontokat kell tesztelni.

(ii) Szerződéses – Nem fogunk belemenni ebbe, és a minőségbiztosítási csapat részvétele ebben az egészben szinte semmi. Az SDLC kezdete előtt elkészített eredeti szerződést felülvizsgálják, és megállapodást kötnek arról, hogy a szerződés minden aspektusát teljesítették-e vagy sem.

Csak az alkalmazás funkcionalitására fogunk összpontosítani .

# 2) Határozza meg a minőségbiztosítás bevonásának körét.

A minőségbiztosítási csapat szerepe a következők egyike:

(i) Nincs részvétel – Ez nagyon ritka.

(ii) Segítség ebben a tesztelésben – A legtöbb gyakori. Ebben az esetben részvételünk képezheti az UAT felhasználókat az alkalmazás használatáról, és készenlétben maradhat a tesztelés során, hogy megbizonyosodhassunk arról, hogy bármilyen nehézség esetén segíthetünk a felhasználóknak. Vagy bizonyos esetekben a készenléti állapot és a segítségnyújtás mellett megoszthatjuk válaszaikat és rögzíthetjük az eredményeket vagy naplózhatjuk a hibákat stb., Miközben a felhasználók elvégzik a tényleges tesztelést.

(iii) Végezze el az UAT-t és jelen eredmények – Ebben az esetben a felhasználók megmutatják az AUT azon területeit, amelyeket ki akarnak értékelni, és magát az értékelést a minőségbiztosítási csapat végzi. Miután elkészült, az eredményeket bemutatják az ügyfeleknek / felhasználóknak, és ők döntenek arról, hogy a kezükben lévő eredmények elegendőek-e vagy sem, és megfelelnek-e elvárásaiknak az AUT elfogadásához. A döntés soha nem a minőségbiztosítási csapat döntése.

Az adott esettől függően döntjük el, melyik megközelítés a legjobb.

Az elsődleges célok és elvárások:

Általában az UAT-ot egy szubjektum-szakértő (SME) és / vagy egy üzleti felhasználó végzi, aki a tesztelt rendszer tulajdonosa vagy megrendelője lehet. A rendszer tesztelési fázisához hasonlóan az UAT fázis magában foglalja a vallási szakaszokat is, mielőtt lezárják.

Az egyes UAT fázisok legfontosabb tevékenységeit az alábbiakban definiáljuk:

UAT irányítása

A rendszervizsgálathoz hasonlóan a UAT-nál is hatékony irányítást alkalmaznak annak biztosítására, hogy erős minőségi kapuk, valamint a meghatározott belépési és kilépési kritériumok mellett (lásd alább **).

** Felhívjuk figyelmét, hogy ez csak útmutatás. Ez a projekt igényei és követelményei alapján módosítható.

UAT teszttervezés

A folyamat majdnem megegyezik a rendszerfázis szokásos teszttervével.

A legtöbb projektben a leggyakoribb megközelítés a rendszer és az UAT tesztelési fázisainak együttes megtervezése. Ha többet szeretne megtudni az UAT teszttervről és annak mintájáról, olvassa el a mellékelt tesztterv dokumentum UAT szakaszait.

Felhasználói elfogadási teszt terv

(Ez ugyanaz, mint amit keresse meg a QA képzési sorozatot is.

Kattintson az alábbi képre, és görgessen lefelé, hogy megtalálja a tesztterv dokumentumának mintáját különböző formátumokban. Ebben a sablonban ellenőrizze az UAT szakaszt.

A dátumok, a környezet, a szereplők (kik), a kommunikációs protokollok, a szerepek és felelősségek, a sablonok, az eredmények és azok elemzési folyamata, a belépés-kilépés kritériumai – mindezek ez és minden más releváns megtalálható az UAT teszttervében.

Akár a minőségbiztosítási csapat részt vesz, részben részt vesz, akár nem vesz részt ebben a tesztben, a mi feladatunk megtervezni ezt a fázist és győződjön meg róla, hogy mindent figyelembe vesznek.

= > Itt van egy felhasználói elfogadás teszt terv mintadokumentum

felhasználói elfogadás tesztelés

Ebben a lépésben a felhasználók által összegyűjtött elfogadási kritériumokat használják. A minták az alábbiak szerint nézhetnek ki.

(Ezek a CSTE CBOK kivonatai. Ez az egyik legjobb referencia a teszteléshez.)

Felhasználói elfogadás tesztelési sablon:

A kritériumok alapján mi (minőségbiztosítási csapat) megadjuk nekik a felhasználóknak az UAT tesztesetek listáját. Ezek a tesztesetek nem különböznek a rendszeres rendszeres teszteseteinktől. Ezek csak egy részhalmaz, mivel az összes alkalmazást a fő funkcionális területekkel szemben teszteljük.

Ezeken felül az adatok, a teszt eredményeinek rögzítésére szolgáló sablonok, adminisztratív eljárások, hibanaplózási mechanizmus, stb., a helyén kell lennie, mielőtt áttérnénk a következő szakaszra.

Teszt végrehajtása

Általában, amikor lehetséges, ez a teszt egy konferencia vagy háborús teremben történik, A felhasználó, a PM, a minőségbiztosítási csapat képviselői egy-két napig együtt ülnek és dolgoznak át az összes elfogadási teszten.

Vagy ha a minőségbiztosítási csapat elvégzi a teszteket, lefuttatjuk a tesztet esetek az AUT-on.

Miután az összes teszt lefutott, és az eredmények kézben voltak, az elfogadásról szóló döntés születik. Ezt nevezzük Go / No-Go döntésnek is. Ha a felhasználók meg vannak győződve arról, hogy ez egy Go, vagy pedig ez egy No-go.

Az elfogadási döntés elérése általában ennek a fázisnak a vége.

Eszközök & Módszertanok

A tesztelési szakaszban használt szoftvereszközök tipikusan hasonlóak a funkcionális tesztelés során használt eszközökhöz.

Eszközök:

Mivel ez a fázis magában foglalja az alkalmazás teljes végponttól végpontig történő validálását, nehéz lehet egyetlen eszközzel rendelkezni az érvényesítés teljes automatizálására. Bizonyos mértékben képesek lennénk felhasználni a rendszer tesztelése során kifejlesztett automatizált szkripteket.

A rendszer teszteléséhez hasonlóan a felhasználók tesztkezelő és hibakezelő eszközöket is használnának, például QC, JIRA stb. eszközök konfigurálhatók a Felhasználói Elfogadás szakasz adatainak összesítésére.

Módszertanok:

Bár a hagyományos módszerek, például a termék UAT-ját végző konkrét üzleti felhasználók továbbra is relevánsak, egy valóban globális szinten A mai világhoz hasonlóan a felhasználói elfogadás tesztelésének időnként országonként eltérő vásárlókat kell bevonnia a termék alapján.

Például egy e-kereskedelmi webhelyet használnának az ügyfelek a világ minden tájáról. Az ilyen esetekben a tömegtesztelés lenne a legjobb életképes megoldás.

A tömegteszt olyan módszer, amelyben a világ minden tájáról érkező emberek részt vehetnek, érvényesíthetik a termék használatát, és javaslatokat és javaslatokat tehetnek.

A tömeges tesztplatformokat sok szervezet építi és használja. Egy olyan webhelyet vagy terméket, amelyet tömegesen kell tesztelni, a platform tárolja, és az ügyfelek kijelölhetik magukat az ellenőrzés elvégzésére. A kapott visszajelzéseket ezután elemzik és rangsorolják.

A tömegtesztelési módszertan hatékonyabbnak bizonyul, mivel az ügyfél pulzusa az egész világon könnyen érthető.

UAT agilis környezetben

Az agilis környezet dinamikusabb jellegű. Az agilis világban az üzleti felhasználókat bevonják a projekt összes futamába, és a projektet tovább fejlesztenék a tőlük kapott visszacsatolási hurkok alapján.

A projekt elején az üzleti felhasználók lennének a legfontosabb érdekeltek követelmény előírása, ezáltal frissítve a termék lemaradását. Minden sprint végén az üzleti felhasználók részt vesznek a sprint bemutatójában, és bármiféle visszajelzés rendelkezésre állnak.

Ezenkívül egy UAT fázist terveznének a sprint befejezése előtt, ahol az üzleti felhasználók megteszik validációk.

A sprint bemutatója és a sprint UAT során kapott visszajelzéseket összevonják és visszahelyezik a termékhátrába, amelyet folyamatosan felülvizsgálnak és prioritásként kezelnek. Így egy agilis világban az üzleti felhasználók közelebb vannak a projekthez, és a hagyományos vízesés projektektől eltérően gyakrabban értékelik ugyanazt a felhasználását.

UAT Team – Szerepek & Feladatok

Egy tipikus UAT-szervezetnek a következő szerepei és felelősségei lennének. Az UAT csapatát a projektmenedzser, a fejlesztő és tesztelő csapatok támogatnák az igényeiknek megfelelően.

Az UAT 7 kihívása És az enyhítési terv

Nem számít, hogy egy milliárd dolláros kiadás része vagy egy induló csapat, le kell küzdenie ezeket a kihívásokat, hogy sikeres szoftvert nyújtson a végfelhasználó számára.

# 1) Környezet beállítása és telepítése:

Ennek a tesztnek a végrehajtása ugyanabban a környezetben, amelyet a funkcionális tesztcsoport használ, minden bizonnyal figyelmen kívül hagyja a valós használati eseteket. Emellett a döntő fontosságú tesztelési tevékenységeket, például a teljesítményteszteket, nem lehet teljes körű tesztadatokkal rendelkező tesztkörnyezetben végrehajtani.

Ehhez a teszthez külön gyártásszerű környezetet kell létrehozni.

Miután az UAT környezet el lett választva a tesztkörnyezettől, hatékonyan ellenőriznie kell a kiadási ciklust. A nem ellenőrzött kiadási ciklus különböző szoftververziókhoz vezethet a teszt és az UAT környezetben. Ha a szoftvert nem a legújabb verzióval tesztelik, az értékes elfogadási tesztidő pazarolódik.

Eközben a hibás szoftververzió hibakövetéséhez szükséges idő magas.

# 2) Teszt Tervezés:

Ezt a tesztelést egyértelmű elfogadási teszttervvel kell megtervezni a követelményelemzés és a tervezés szakaszában.

A stratégia tervezésében meg kell határozni a valós felhasználási esetek halmazát. végrehajtásra. Nagyon fontos meghatározni ennek a tesztnek a tesztcélkitűzéseit, mivel ebben a tesztelési fázisban nagy alkalmazások esetében a teljes tesztfuttatás nem lehetséges. A tesztelést először a kritikus üzleti célok rangsorolásával kell végrehajtani.

Ezt a tesztelést a tesztelési ciklus végén hajtják végre. Nyilvánvaló, hogy ez a legkritikusabb időszak a szoftverkiadás szempontjából. A fejlesztés és a tesztelés bármelyik szakaszának késése megemeli az UAT idejét.

A helytelen teszttervezés a legrosszabb esetben is átfedést eredményez a rendszer tesztelése és az UAT között. A határidők betartására fordított kevesebb idő és nyomás miatt a szoftvert akkor is telepítik ebbe a környezetbe, ha a funkcionális tesztelés nem fejeződik be. Ennek a tesztnek az alapvető céljait nem lehet elérni ilyen helyzetekben.

Az UAT teszttervet jóval a teszt megkezdése előtt el kell készíteni és közölni kell a csapattal. Ez segít nekik a teszttervezésben, tesztesetek & tesztparancsfájlok megírásában és UAT-környezet létrehozásában.

# 3) Az új üzleti követelmények kezelése eseményként / hibaként:

A követelmények kétértelműségei elakadnak az UAT szakaszában. Az UAT tesztelői a kétértelmű követelmények miatt felmerülő problémákat találják meg (a teljes felhasználói felületet megvizsgálva, amely a követelménygyűjtés szakaszában nem volt elérhető), és hibaként regisztrálják.

Az ügyfél elvárja, hogy ezeket a jelenlegi kiadásban javítsák, anélkül, hogy figyelembe vennék a változtatási kérelmek idejét. Ha a projektvezetés nem hoz időben döntést ezekről a last-minute változtatásokról, az a kiadás meghiúsulásához vezethet.

# 4) Képzetlen tesztelők vagy üzleti ismeretek nélküli tesztelők:

Ha nincs állandó csapat, a vállalat kiválasztja az UAT munkatársait a különböző belső osztályokról.

Még akkor is, ha a személyzet jól ismeri az üzleti igényeket, vagy ha nincsenek kiképezve az új követelményekhez. fejlesztés alatt állnak, nem tudnak hatékony UAT-t végrehajtani. Ezenkívül egy nem technikai üzleti csapatnak sok technikai nehézséggel kell szembenéznie a tesztesetek végrehajtása során.

Eközben a tesztelők kijelölése az UAT ciklus végén nem jelent semmilyen értéket a projekt számára. Az UAT személyzetének kiképzésére fordított kevés idő jelentősen növelheti az UAT sikerének esélyét.

# 5) Helytelen kommunikációs csatorna:

A távoli fejlesztés, tesztelés és az UAT csapata közötti kommunikáció nehezebb . Az e-mailes kommunikáció gyakran nagyon nehéz, ha offshore technikai csapata van. A baleseti jelentésekben rejlő apró kétértelműség késleltetheti a megoldást egy napra.

A megfelelő tervezés és a hatékony kommunikáció elengedhetetlen a csapat hatékony együttműködéséhez. A projektcsoportoknak webalapú eszközt kell használniuk a hibák és kérdések naplózására. Ez elősegíti a munkaterhelés egyenletes elosztását és elkerüli az ismétlődő problémák jelentését.

# 6) A funkcionális tesztcsoport felkérése a teszt elvégzésére:

Nincs rosszabb helyzet, mint a funkcionális teszt megkérdezése csapat az UAT elvégzésére.

Az ügyfelek erőforrások hiánya miatt hárítják felelősségüket a tesztcsoportra. A teszt teljes célja ilyen esetekben veszélybe kerül. Amint a szoftver életbe lép, a végfelhasználók gyorsan észreveszik azokat a problémákat, amelyeket a funkcionális tesztelők nem tekintenek valós forgatókönyvnek.

Erre megoldást jelent, ha ezt a tesztelést elkötelezett és hozzáértő szakemberhez rendelik. üzleti ismeretekkel rendelkező tesztelők.

# 7) A hibás játék

Az üzleti felhasználók néha csak megpróbálnak okokat találni a szoftver elutasítására. Lehet, hogy öntudatuk megmutatni, mennyire fölényesek, vagy hibáztatni a fejlesztő és tesztelő csapatot azért, hogy tiszteletet szerezzenek az üzleti csapatban. Ez nagyon ritka, de a belső politikával rendelkező csapatokban fordul elő.

Nagyon nehéz kezelni az ilyen helyzeteket. Az üzleti csapattal való pozitív kapcsolat kiépítése azonban mindenképpen segítene elkerülni a hibáztató játékot.

Remélem, hogy ezek az irányelvek minden bizonnyal segítséget nyújtanak a sikeres felhasználói elfogadási terv végrehajtásában a különböző kihívások leküzdésével. A megfelelő tervezés, kommunikáció, végrehajtás és a motivált csapat a kulcs a sikeres felhasználói elfogadási teszthez.

Rendszer tesztelése Vs Felhasználói elfogadás tesztelés

A tesztelő csapat bevonása a a projekt már a követelményelemzési fázistól kezdve.

A projekt életciklusán keresztül valamilyen érvényesítést hajtanak végre a projekt számára, azaz statikus tesztelés, egység tesztelés, rendszer tesztelés, integrációs tesztelés, végpontok közötti tesztelés vagy regressziós teszt. Ez jobban megért bennünket az UAT fázisban végzett tesztelésben és abban, hogy mennyiben különbözik a korábban elvégzett többi teszttől.

Bár látjuk a SIT és az UAT különbségeit, fontos, hogy kihasználjuk a szinergiákat. de továbbra is fenntartsa a két fázis közötti függetlenséget, ami lehetővé tenné a gyorsabb piacra kerülést.

Következtetés

# 1) Az UAT nem az oldalakról, mezőkről vagy gombokról szól. Az alapfeltevés már a teszt megkezdése előtt is az, hogy az összes alapvető dolgot tesztelik és jól működnek. Ne adj isten, a felhasználók egy ilyen alapvető hibát találnak – ez egy nagyon rossz hír a QA csapat számára. 🙁

# 2) Ez a teszt az entitásról szól, amely a vállalkozás elsődleges eleme.

Hadd mondjak egy példát: Ha az AUT egy jegyrendszer, akkor a Az UAT nem arról szól, hogy keressen egy menüt, amely megnyit egy oldalt, stb. Ez a jegyekről és azok lefoglalásáról, a lehetséges állapotokról, a rendszeren keresztüli utazásáról stb. Szól.

Egy másik példa, ha a helyszín autószalon, akkor a hangsúly az “autó és annak értékesítése”, és nem a helyszínen van. Ennélfogva az alaptevékenység az, amit ellenőriznek és validálnak, és ki jobb, ha ezt elvégzi, mint a cégtulajdonosok. Ezért van ez a teszt akkor a legértelmesebb, ha az ügyfelet jelentős mértékben bevonják.

# 3) Az UAT a tesztelés egyik formája is, ami azt jelenti, hogy jó esély van a tesztelésre. néhány hiba felismerése ebben a szakaszban is. Néha előfordul. Eltekintve attól a ténytől, hogy ez a QA-csapat jelentős eszkalációja, az UAT-hibák általában értekezletet jelentenek, hogy üljenek és megvitassák, hogyan kezeljék őket follo-ként. Ezt a tesztet általában nincs idő kijavítani és újra tesztelni.

A döntés a következő lehet:

• Nyomja meg az éles dátumot, először javítsa ki a problémát, majd lépjen tovább.
• Hagyja a hibát úgy, ahogy van.
• Tekintsük a jövőbeli kiadások módosítási kérelmének részeként.

# 4) Az UAT alfa és béta tesztelésnek minősül, de ez a besorolás nem annyira fontos a szolgáltatás-alapú iparág tipikus szoftverfejlesztési projektjeivel összefüggésben.

• Az alfa-tesztelés az, amikor az UAT-ot a szoftver-készítő környezetében hajtják végre, és jelentősebb a polcról elérhető kereskedelemben. szoftver.
• Béta tesztelés az, amikor az UAT-t a termelési környezetben vagy az ügyfél környezetében hajtják végre. Ez gyakrabban fordul elő az ügyfél felé fordított alkalmazásoknál. Az itteni felhasználók a tényleges ügyfelek, mint te és én ebben az összefüggésben.

# 5) A szokásos szoftverfejlesztési projektben az UAT legtöbbször a minőségbiztosítási környezetben valósul meg, ha van ilyen. nem stádium- vagy UAT-környezet.

Röviden, a legjobb módja annak kiderítésére, hogy terméke elfogadható-e és alkalmas-e a rendeltetésére, az, ha valóban a felhasználók elé állítja.

A szervezetek agilis szállítási módot vesznek igénybe, az üzleti felhasználók egyre jobban részt vesznek, a projekteket pedig tovább fejlesztik és visszacsatolási ciklusokon keresztül valósítják meg. Mindezek után a Felhasználói Elfogadás fázist tekintjük a megvalósítás és a gyártás felé vezető kapunak.

Mi volt az UAT tapasztalata? Készenléti állapotban volt, vagy tesztelte a felhasználókat? Találtak-e problémákat a felhasználók? Ha igen, hogyan bánt velük?

= > Itt olvassa el a sorozat ÖSSZES oktatóanyagát is.

= > Látogasson el ide a teljes tesztterv-oktatósorozatért