IT Systems Integration Consultant
Acceptance testing & UAT testing: definícia, typy a priebeh
UAT testing (user acceptance testing) je záverečná fáza testovania softvéru pred nasadením do produkcie. Overuje, či systém spĺňa požiadavky zadávateľa a koncových používateľov. Nie z pohľadu technického tímu, ale z pohľadu tých, ktorí budú produkt skutočne používať. V článku nájdeš definíciu acceptance testingu a UAT testingu, ich typy, priebeh UAT procesu krok za krokom, UAT checklist a best practices.
V článku sa dozvieš:
Čo je akceptačné testovanie (acceptance testing)
UAT testing je typ softvérového testovania, pri ktorom sa overuje, či produkt spĺňa vopred definované akceptačné kritériá a biznis požiadavky. Je to záverečná fáza SDLC (software development lifecycle) pred nasadením do produkcie.
Acceptance testing patrí medzi black box testing (testovanie čiernej skrinky), t. j. testeri nevidia vnútornú štruktúru kódu, overujú len správnosť funkcionálneho správania systému. Cieľom nie je hľadať technické chyby, ale potvrdiť: „Systém robí to, čo sme si objednali“.
V kontexte typov softvérového testovania je acceptance testing nadradený QA testovaniu. Nastupuje až po tom, čo QA tím potvrdil technickú funkčnosť systému.
Kedy sa robí UAT testing v SDLC?
UAT testovanie sa vykonáva na samom konci SDLC — po systémovom testovaní, integračnom testovaní a regresnom testovaní, tesne pred nasadením do produkcie.
Vieš, že…
…až 70 % softvérových projektov prekročí rozpočet alebo termín? Jedným z hlavných dôvodov je chýbajúce alebo zle nastavené akceptačné testovanie (acceptance testing). UAT testing odhaluje požiadavky, ktoré si klient predstavoval inak, než ich vývojári implementovali, a to ešte pred nasadením do produkcie.
| Fáza testovania | Kto testuje | Čo overuje |
|---|---|---|
| Unit testing | Vývojár | Jednotlivé funkcie a moduly kódu |
| Integration testing | QA tím | Spolupráca medzi komponentmi |
| System testing | QA tím | Celý systém ako celok |
| UAT testing | Koncoví používatelia / zadávateľ | Splnenie biznis požiadaviek |
UAT je teda posledná vrstva kontroly pred produkciou — a jediná, ktorú vykonávajú nie testeri, ale samotní zadávatelia alebo koncoví používatelia. Práve preto sa v odbornej literatúre stretneš aj s pojmom UAT v softvérovom testovaní (UAT in software testing).
Výhody a nevýhody akceptačného testovania
Acceptance testing prináša jasné benefity, ale aj obmedzenia, ktoré treba zvážiť pri plánovaní projektu.
Výhody akceptačného testovania
Medzi výhody akceptačného testovania patrí najmä, že:
- Overuje splnenie biznis požiadaviek pred nasadením – znižuje riziko, že klient produkt odmietne
- Odhaľuje funkčné nedostatky, ktoré technické testovanie prehliadlo
- Zapája koncových používateľov do procesu – zvyšuje ich dôveru v produkt
- Slúži ako právny a procesný základ pre nasadenie (UAT sign-off dokument)
- Odhaľuje medzery medzi dokumentáciou požiadaviek a reálnou implementáciou
Nevýhody akceptačného testovania
Avšak UAT testing má aj nevýhody. Testovanie je:
- Časovo náročné – zapojenie reálnych používateľov vyžaduje koordináciu a plánovanie
- Nákladné pri nedostatočnej príprave – defekty nájdené neskoro v SDLC sú drahšie na opravu
- Ťažko štandardizovateľné – rôzni používatelia testujú rôzne veci, bez štruktúry chýbajú scenáre
- Nemá zmysel po každej malej zmene – pre mikro updates stačí regresné testovanie
- Kvalita UAT závisí od aktivity používateľov – nezainteresovaní používatelia testujú povrchne
Odporúčame ti…
UAT nevykonávaj po každej malej zmene. Rezervuj ho pre významné releasy, nové funkcie alebo zmeny, ktoré priamo ovplyvňujú biznis procesy klienta. Pre malé opravy postačí regresné testovanie od QA tímu.
Typy akceptačného testovania (acceptance testing types)
Acceptance testing nie je jediný typ. Existuje viacero foriem, z ktorých každá je určená pre iný kontext a iný typ zákazníka. Tu sú hlavné typy UAT:
UAT: User Acceptance Testing
UAT testing overuje, či systém spĺňa požiadavky koncových používateľov. Vykonáva ho zadávateľ alebo reprezentatívna skupina skutočných používateľov tesne pred nasadením do produkcie. Je to najrozšírenejší typ acceptance testovania.
BAT: Business Acceptance Testing
BAT (Business Acceptance Testing) overuje, či systém spĺňa biznis požiadavky a SLA (Service Level Agreement). Zameriava sa na to, či produkt prispeje k obchodným cieľom firmy a nielen na funkčnosť.
CAT: Contract Acceptance Testing
CAT (Contract Acceptance Testing) testuje systém oproti presne definovaným zmluvným požiadavkám. Využíva sa pri dodávkach softvéru na zákazku, kde kontrakt definuje akceptačné kritériá.
RAT: Regulation Acceptance Testing
RAT (Regulation Acceptance Testing) overuje súlad systému s regulačnými a zákonnými požiadavkami, napr. GDPR, finančné regulácie, zdravotnícke normy. V poistenectve a financiách je RAT povinný.
OAT: Operational Acceptance Testing
OAT (Operational Acceptance Testing) testuje operačnú pripravenosť systému: zálohovanie, obnova po havárii, správa používateľov, monitoring. Vykonáva ho IT operačný tím pred prechodom do produkcie.
Alpha testing (alfa testovanie)
Alfa testovanie (alpha testing) vykonáva interný tím výrobcu – testeri, QA inžinieri alebo zamestnanci. Prebieha v riadenom prostredí ešte pred vydaním produktu vonkajším používateľom. Je prvou fázou acceptance testovania pre konzumný softvér.
Beta testing (beta testovanie)
Beta testovanie (beta testing) vykonáva obmedzená skupina reálnych používateľov mimo firmy výrobcu. Beta test je verejná alebo uzavretá fáza, kde produkt testujú tí, čo ho budú skutočne používať.
Ako prebieha UAT proces
Proces UAT testovania (UAT testing process) má 5 hlavných krokov. Každý krok má jasného vlastníka a výstup, bez ktorého nemá zmysel pokračovať ďalej.
Krok 1: Plánovanie UAT
QA tím alebo projektový manažér pripraví testovací plán (test plan). Ten definuje rozsah UAT, akceptačné kritériá (acceptance criteria), harmonogram, testovacích používateľov a prostredie. Bez schváleného plánu je UAT nekontrolovateľné.
Odporúčame ti…
Akceptačné kritériá definuj ešte pred začatím vývoja – nie až pri UAT. Ak kritériá vzniknú až na konci projektu, často odrážajú to, čo bolo implementované, nie to, čo klient skutočne potreboval.
Krok 2: Príprava testovacieho prostredia a dát
Pre UAT je nevyhnutné separátne testovacie prostredie, ktoré reálne simuluje produkciu. Nikdy netestuj priamo v produkcii. Pripravia sa testovacie dáta, prístupové práva pre UAT testerov a dokumentácia požiadaviek.
Krok 3: Tvorba akceptačných testovacích prípadov
Vytvoria sa akceptačné testovacie prípady (acceptance test cases). Sú to štruktúrované scenáre, ktoré overujú splnenie každej biznis požiadavky. Každý test case obsahuje vstupné podmienky, kroky a očakávaný výsledok (pass/fail).
Pri tvorbe test cases zahrň aj negatívne testovanie – scenáre, kde používateľ zadá nesprávne alebo hraničné hodnoty. Koncoví používatelia často testujú len tzv. „happy path” a prehliadnu chybové stavy.
Krok 4: Vykonávanie testov a zaznamenávanie defektov
Koncoví používatelia alebo zadávateľ vykonajú testy podľa pripraveného scenára. Každý defekt sa zaznamenáva s popisom, prioritou a reprodukovateľným krokom. Na evidenciu defektov sa často využíva Jira alebo TestRail.
Počas testovania prebieha priebežná komunikácia s vývojovým tímom (development team). Kritické defekty sa opravujú hneď, menej závažné sa zaraďujú do backlogu.
Krok 5: UAT sign-off a rozhodnutie o nasadení
Po dokončení UAT zainteresované strany podpíšu UAT sign-off dokument. Ide o formálny súhlas, že systém spĺňa akceptačné kritériá a je pripravený na nasadenie. Pri neakceptovateľných defektoch nasleduje oprava a opakovaný test. Výsledkom je rozhodnutie go/no-go pre produkciu.
UAT testing: príklady a reálny use case
Príklady UAT testovania (user acceptance testing examples) z poisťovacieho prostredia pomáhajú pochopiť, čo UAT testing v realite znamená.
Predstav si poisťovaciu spoločnosť, ktorá nasadzuje novú funkciu pre online podávanie hlásenia škôd. Vývojový tím odovzdal systém po systémovom testovaní. Nasleduje UAT:
- Pracovník poisťovacej agentúry skontroluje, či vie prejsť novým formulárom od začiatku do konca bez chýb.
- Overuje, či systém správne prepočíta náhradu podľa zmluvných podmienok (BAT kritérium).
- Testuje, či je formulár použiteľný na tablete (OAT kritérium – prenositeľnosť).
- Skontroluje, či logovanie spĺňa požiadavky GDPR (RAT kritérium).
Každý UAT test case má presne definovaný očakávaný výsledok. Ak používateľ pri teste narazí na neočakávané správanie, vytvorí bug report a defekt sa priradí do systému riadenia defektov. Exploratory testing sa používa skôr, pri UAT už ide o štruktúrované overovanie podľa definovaných kritérií.
UAT test case
| Pole | Príklad |
|---|---|
| ID | UAT-001 |
| Názov | Odoslanie nového hlásenia škody cez webový formulár |
| Predpoklad | Používateľ je prihlásený, má aktívnu poistku |
| Kroky | 1. Kliknúť na „Nahlásiť škodu” 2. Vyplniť všetky povinné polia 3. Nahrať fotografiu 4. Odoslať formulár |
| Očakávaný výsledok | Formulár je uložený, používateľ dostane potvrdenie e-mailom do 2 minút |
| Skutočný výsledok | (vyplní tester) |
| Status | Pass/fail |
UAT vs. system testing vs. integration testing
Keď sa pozrieme na UAT vs QA testovanie, rozdiel je v tom, kto testuje a čo overuje. QA tím overuje technickú správnosť – či systém funguje podľa špecifikácie. UAT overuje biznis správnosť, či systém robí to, čo klient skutočne potrebuje.
| Kritérium | Integration testing | System testing | UAT testing |
|---|---|---|---|
| Čo testuje | Komunikáciu medzi komponentmi | Celý systém ako celok | Splnenie biznis požiadaviek |
| Kto testuje | QA / vývojár | QA tím | Koncoví používatelia / zadávateľ |
| Kedy v SDLC | Po unit testovaní | Po integračnom testovaní | Pred nasadením do produkcie |
| Typ testovania | Grey/white box | Black box | Black box |
| Cieľ | Overiť integráciu | Overiť funkčnosť systému | Overiť biznis akceptáciu |
UAT testing nie je náhrada za systémové ani integračné testovanie. Je to posledná vrstva pred produkciou. Každá fáza má iný cieľ a iný typ chýb, ktoré dokáže odhaliť.
Nástroje pre UAT testing
Správne nástroje zefektívnia UAT proces od plánovania test cases až po evidenciu defektov a UAT sign-off. Tu sú najčastejšie používané nástroje UAT testingu:
TestRail
TestRail je nástroj pre správu testovacích prípadov, ktorý UAT tímom umožňuje organizovať test cases, sledovať výsledky testovania a generovať reporty pre sign-off. Ideálne pre štruktúrované UAT s viacerými testovacími cyklami.
Jira
Jira slúži na evidenciu defektov a sledovanie stavu opráv počas UAT. Každý bug report sa vytvorí ako Jira issue s prioritou, assignee a reprodukčnými krokmi. V kombinácii so Zephyr pokryje celý UAT cyklus od test case až po sign-off.
Confluence
Confluence sa využíva na dokumentáciu UAT plánu, akceptačných kritérií a UAT sign-off dokumentu. Centralizuje všetku dokumentáciu na jednom mieste dostupnom celému tímu.
Odporúčame ti…
Pre UAT testing kombinuj TestRail na správu test cases a Jiru na evidenciu defektov. Oba nástroje sa integrujú – defekty z TestRailu sa priamo prepájajú do Jira issues bez ručného prepisovania.
UAT checklist: Na čo nezabudnúť pred a počas UAT
Dobre pripravený UAT checklist je rozdiel medzi chaotickým a úspešným akceptačným testovaním. Tu je UAT testing checklist rozdelený do troch fáz:
Pred UAT
- Definované a schválené akceptačné kritériá (zadávateľ podpísal)
- Pripravený a schválený UAT plán (testovací plán)
- Separátne testovacie prostredie dostupné a stabilné
- Vybraný a inštruovaný tím UAT testerov
- Dokumentácia požiadaviek je aktuálna a dostupná
- Pripravené testovacie dáta (realistické, ale nie produkčné dáta)
- Vytvorené akceptačné testovacie prípady (test cases) schválené biznis tímom
- Pripravený UAT testing template — väčšina test management nástrojov ako TestRail alebo Zephyr ponúka predpripravené šablóny, ktoré môžeš upraviť podľa projektu
Počas UAT
- Zaznamenávanie všetkých defektov s prioritou a reprodukčnými krokmi
- Sledovanie pokrytia test cases – ktoré sú vykonané, ktoré ešte nie
- Priebežná komunikácia s vývojovým tímom pri kritických defektoch
- Aktualizácia výsledkov testovania v reálnom čase (TestRail / Jira)
- Kontrola pass/fail statusu pre každý test case
Po UAT
- Zoznam všetkých otvorených defektov (known issues) so statusom a prioritou
- UAT sign-off dokument podpísaný všetkými zainteresovanými stranami
- Rozhodnutie go/no-go pre nasadenie do produkcie
- Archivácia všetkých UAT dokumentov a výsledkov
Best practices pre úspešné UAT
Úspešné UAT nespočíva len v nasledovaní procesu – záleží aj na tom, ako tím pristupuje k testovaniu a komunikácii:
- Zapoj skutočných používateľov, nie len QA tím. UAT má zmysel, len ak ho vykonávajú tí, čo systém budú skutočne používať. Interný QA tím testuje technickú správnosť – koncoví používatelia testujú biznis realitu.
- Definuj akceptačné kritériá ešte pred začatím vývoja. Kritériá definované až pri UAT často odrážajú to, čo bolo implementované, nie to, čo klient potreboval. Nevyhnutnou podmienkou úspešného UAT sú jasné kritériá stanovené hneď na začiatku.
- UAT prostredie musí byť separátne od produkcie. Testovanie priamo v produkcii je neakceptovateľné – riziko poškodiť reálnych používateľov a dáta je príliš vysoké.
- Dokumentuj všetko. UAT sign-off dokument je právny a procesný základ pre nasadenie. Bez neho nemáš dokazateľnú akceptáciu zo strany zadávateľa.
- Nepleť UAT s finálnym regresným testovaním. Regresné testovanie robí QA tím pred UAT. Úlohou koncových používateľov pri UAT nie je hľadať technické regresy – je to zistiť, či systém plní ich biznis potreby.
FAQ: Často kladené otázky o UAT testovaní
Čo je UAT testing?
UAT testing (user acceptance testing) je záverečná fáza testovania softvéru, pri ktorej koncoví používatelia alebo zadávateľ overujú, či systém spĺňa biznis požiadavky a akceptačné kritériá. Prebieha po systémovom testovaní, pred nasadením do produkcie.
Aký je rozdiel medzi UAT a QA testovaním?
Keď sa pozrieme na UAT vs QA testovanie, rozdiel je v tom, kto testuje a čo overuje. QA tím overuje technickú správnosť systému — teda či funguje bez chýb. UAT overuje biznis správnosť, či systém robí to, čo klient skutočne potrebuje. QA testovanie prebieha v skorších fázach SDLC, UAT je posledná vrstva pred produkciou.
Je UAT testing náročný? Aké zručnosti potrebujem?
UAT testing nevyžaduje programátorské zručnosti. Testerom môže byť aj bežný biznis používateľ. Nevyhnutné sú znalosť biznis procesov, schopnosť popísať defekt reprodukovateľne a pochopenie akceptačných kritérií. Pre organizátora UAT sú dôležité projektové riadenie a komunikačné zručnosti.
Aký je príklad UAT testu?
Príklad UAT testu z poisťovacieho prostredia: používateľ overí, či vie správne vyplniť a odoslať hlásenie škody cez webový portál. Test case definuje vstupné podmienky, kroky a očakávaný výsledok (napr. potvrdenie prijatia emailom do 2 minút). Detailný príklad akceptačného testovacieho prípadu nájdeš vyššie v článku.
Záver
UAT testing je posledná nevyhnutná vrstva ochrany pred nasadením softvéru do produkcie. Dobre nastavené akceptačné testovanie zachráni projekt pred draho opravovanými defektami, ktoré by objavil až zákazník.
Kľúč k úspešnému UAT je v príprave: jasné akceptačné kritériá, separátne prostredie, štruktúrované test cases a zapojenie skutočných používateľov. Ak chceš vedieť viac o tom, ako zapadajú rôzne typy testovania do seba, pozri sa na typy softvérového testovania alebo na rolu QA testera v praxi.
Zdroje:
https://www.testrail.com/blog/user-acceptance-testing/
https://www.panaya.com/blog/testing/what-is-uat-testing/
https://glossary.istqb.org/
https://www.guru99.com/user-acceptance-testing.html
https://www.practitest.com/resource-center/article/what-is-uat-testing/
