what is user acceptance testing
Zistite, čo je testovanie používateľskej akceptácie (UAT), spolu s jeho definíciou, typmi, krokmi a príkladmi:
Moje pravidlo číslo jeden pri pokuse o pochopenie nového konceptu je, že: meno bude vždy relevantné a väčšinou bude mať doslovný význam (v technickom kontexte).
Zistenie, čo to je, poskytne prvé pochopenie a pomôže mi začať.
html otázky a odpovede na pohovor pdf
=> Kliknutím sem zobrazíte kompletnú sériu návodov na kompletný testovací plán
Vyskúšajme tento koncept.
=> Prečítajte si všetky návody v našej sérii Acceptance Testing.
Čo sa dozviete:
- Čo je testovanie prijatia používateľom?
- 7 výziev UAT a plán zmierňovania
- Testovanie systému vs. Testovanie prijatia používateľa
- Záver
Čo je testovanie prijatia používateľom?
Vieme, čo je testovanie, prijatie znamená schválenie alebo dohodu. Užívateľom v súvislosti so softvérovým produktom je buď spotrebiteľ softvéru, alebo osoba, ktorá požiadala o jeho vytvorenie (klient).
Podľa môjho pravidla teda bude mať definíciu:
User Acceptance Testing (UAT), známe tiež ako beta alebo testovanie koncovým používateľom, je definované ako testovanie softvéru používateľom alebo klientom s cieľom zistiť, či je alebo nie je možné ho akceptovať. Toto je záverečné testovanie, ktoré sa vykoná po dokončení funkčného, systémového a regresného testovania.
Hlavným účelom tohto testovania je overiť softvér podľa obchodných požiadaviek. Túto validáciu vykonávajú koncoví používatelia, ktorí sú oboznámení s obchodnými požiadavkami.
UAT, alfa a beta testovanie sú rôzne typy prijímacích skúšok.
Pretože test prijatia používateľa je posledným testovaním, ktoré sa vykonáva pred uvedením softvéru do prevádzky, je to zjavne posledná šanca pre zákazníka otestovať softvér a zmerať, či je vhodný na daný účel.
Kedy sa vykonáva?
Toto je zvyčajne posledný krok pred uvedením produktu do prevádzky alebo pred prijatím dodávky produktu. To sa vykonáva po dôkladnom otestovaní samotného produktu (t. J po testovaní systému ).
Kto vykonáva UAT?
Používatelia alebo klient - Môže to byť buď niekto, kto kupuje produkt (v prípade komerčného softvéru), alebo niekto, kto si nechal softvér vyrobiť na mieru prostredníctvom poskytovateľa softvérových služieb alebo koncový používateľ, ak je im softvér sprístupnený. pred časom a keď sa vyhľadá ich spätná väzba.
Tím môže pozostávať z beta testerov alebo by si zákazník mal interne vyberať členov UAT z každej skupiny organizácie, aby bolo možné príslušne testovať každú rolu používateľa.
Potreba testovania prijatia používateľom
Vývojári a testeri funkčnosti sú technickí ľudia, ktorí overujú softvér podľa funkčné špecifikácie . Interpretujú požiadavky podľa svojich znalostí a vyvíjajú / testujú softvér (tu je dôležitá znalosť domény).
Tento softvér je kompletný v súlade s funkčnými špecifikáciami, ale existujú určité obchodné požiadavky a procesy, ktoré sú známe iba koncovým používateľom. Chýbajú pri komunikácii alebo sú nesprávne interpretované.
Toto testovanie hrá dôležitú úlohu pri overovaní, či sú alebo nie sú splnené všetky obchodné požiadavky, ešte pred uvedením softvéru na trh. Vďaka použitiu živých údajov a skutočným prípadom použitia je toto testovanie dôležitou súčasťou cyklu vydávania.
Mnoho firiem, ktoré utrpeli veľké straty v dôsledku problémov po vydaní, vie o dôležitosti úspešného testu akceptácie používateľov. Náklady na opravu chýb po uvoľnení sú mnohonásobne vyššie ako náklady na odstránenie chýb predtým.
Je UAT skutočne nevyhnutný?
Po vykonaní množstva systému, integrácie a regresného testovania by ste sa čudovali nad nevyhnutnosťou tohto testovania. V skutočnosti je to najdôležitejšia fáza projektu, pretože to je čas, v ktorom by používatelia, ktorí skutočne budú systém používať, overili jeho vhodnosť na daný účel.
UAT je testovacia fáza, ktorá do značnej miery závisí od pohľadu koncových používateľov a doménových znalostí oddelenia, ktoré ich zastupuje.
V skutočnosti by bolo skutočne užitočné, keby obchodné tímy boli zapojené do projektu pomerne skoro, aby mohli poskytnúť svoje názory a príspevky, ktoré by pomohli efektívne využiť systém v reálnom svete.
Proces testovania prijatia používateľa
Najjednoduchší spôsob, ako pochopiť tento proces, je myslieť na to ako na projekt autonómneho testovania - čo znamená, že bude mať fázy plánu, návrhu a vykonania.
Pred začatím fázy plánovania sú potrebné predpoklady:
# 1) Získajte kľúčové kritériá prijatia
Zjednodušene povedané, kritériá prijatia sú zoznamom vecí, ktoré sa pred prijatím produktu vyhodnotia.
Môžu to byť dva typy:
(i) Funkčnosť aplikácie alebo súvisiace s podnikaním
V ideálnom prípade by mali byť overené všetky kľúčové podnikové funkcie, ale z rôznych dôvodov vrátane času nie je praktické robiť všetko. Stretnutie s klientom alebo používateľmi, ktorí sa majú zapojiť do tohto testovania, nám preto môže poskytnúť predstavu o tom, koľko testovania sa bude týkať a aké aspekty sa budú testovať.
(ii) Zmluvné - Nejdeme sa do toho púšťať a zapojenie tímu QA do tohto všetkého je takmer nič. Počiatočná zmluva, ktorá sa uzavrie ešte pred začiatkom SDLC, sa skontroluje a dospeje sa k dohode o tom, či boli alebo neboli dodané všetky aspekty zmluvy.
Zameriame sa iba na funkčnosť aplikácií.
# 2) Definujte rozsah zapojenia QA.
Úloha tímu QA je jedna z nasledujúcich:
i) Žiadna účasť - Toto je veľmi zriedkavé.
ii) Pomáhať pri tomto testovaní - Najbežnejší. V tomto prípade by mohlo byť naším zapojením školenie používateľov UAT o tom, ako používať aplikáciu, a pohotovostný režim počas tohto testovania, aby sme sa uistili, že používateľom môžeme pomôcť v prípade akýchkoľvek ťažkostí. Alebo v niektorých prípadoch okrem toho, že sme v pohotovostnom režime a pomáhame, môžeme zdieľať ich odpovede a zaznamenávať výsledky alebo zaznamenávať chyby atď., Zatiaľ čo používatelia vykonávajú skutočné testovanie.
(iii) Vykonať UAT a predložiť výsledky - Ak je to tak, používatelia ukážu na oblasti AUT, ktoré chcú hodnotiť, a samotné hodnotenie vykoná tím QA. Po dokončení sa výsledky predložia klientom / používateľom a tí sa rozhodnú, či sú výsledky, ktoré majú v rukách, dostatočné alebo nie a v súlade s ich očakávaniami, aby mohli prijať AUT. Rozhodnutie nikdy nie je rozhodnutím tímu QA.
Podľa konkrétneho prípadu rozhodujeme, ktorý prístup je najlepší.
Hlavné ciele a očakávania:
Spravidla UAT vykonáva Expert na predmetové záležitosti (SME) alebo komerčný užívateľ, ktorý môže byť vlastníkom alebo zákazníkom testovaného systému. Podobne ako fáza testovania systému, aj fáza UAT zahrnuje náboženské fázy predtým, ako sa uzavrie.
Kľúčové aktivity každej fázy UAT sú definované nižšie:
Správa UAT
Podobne ako pri testovaní systému, aj pri UAT sa presadzuje efektívne riadenie, aby sa zabezpečila vysoká kvalita brán spolu s definovanými kritériami vstupu a výstupu (uvedené nižšie **).
** Upozorňujeme, že ide iba o usmernenie. To by sa dalo upraviť na základe potrieb a požiadaviek projektu.
Plánovanie testu UAT
Proces je takmer rovnaký ako v prípade plán pravidelných skúšok vo fáze systému.
Najbežnejším prístupom, ktorý sa uplatňuje vo väčšine projektov, je spoločné plánovanie oboch fáz testovania systému a UAT. Ďalšie informácie o pláne skúšok UAT spolu so vzorkou nájdete v oddieloch dokumentu UAT priloženého dokumentu plánu skúšok.
Plán testov prijatia používateľa
(To je to isté, čo by ste našli aj na našej stránke pre tréningové série QA).
Kliknite na obrázok nižšie a posuňte sa nadol, aby ste našli vzorku dokumentu plánu testov v rôznych formátoch. V tejto šablóne skontrolujte sekciu UAT.
Dátumy, prostredie, aktéri (kto), komunikačné protokoly, úlohy a zodpovednosti, šablóny, výsledky a proces ich analýzy, vstupno-výstupné kritériá - to všetko a všetko ostatné, čo je relevantné, nájdete v testovacom pláne UAT.
Či už sa tím QA zúčastňuje, čiastočne zúčastňuje alebo sa vôbec nezúčastňuje tohto testu, je našou úlohou naplánovať túto fázu a zabezpečiť, aby bolo zohľadnené všetko.
=> Tu je vzorový dokument plánu testovania prijatia používateľa
Dizajn testovania prijatia používateľa
V tomto kroku sa použijú zhromaždené kritériá prijatia od používateľov. Vzorky môžu vyzerať, ako je uvedené nižšie.
(Toto sú výňatky z CSTE CBOK . Toto je jeden z najlepších dostupných referencií o tomto testovaní.)
Šablóna na testovanie prijatia používateľa:
Na základe kritérií im (tím QA) poskytneme používateľom zoznam testovacích prípadov UAT. Tieto testovacie prípady sa nelíšia od našich bežných testovacích prípadov systému. Sú iba podmnožinou, pretože testujeme všetky aplikácie, ktoré sú protikladom, iba ku kľúčovým funkčným oblastiam.
Okrem nich musia byť predtým, ako prejdeme do ďalšej fázy, k dispozícii údaje, šablóny na zaznamenávanie výsledkov testov, administratívne postupy, mechanizmus zaznamenávania chýb atď.
Vykonanie testu
Zvyčajne, ak je to možné, sa toto testovanie uskutoční v konferencii alebo vo vojnovej miestnosti, kde sú používatelia, zástupcovia tímov PM a QA všetci spolu jeden deň alebo dva a prechádzajú všetkými prípadmi prijímacích testov.
Alebo v prípade, že testy vykoná tím QA, spustíme testovacie prípady na AUT.
Po vykonaní všetkých testov a získaní výsledkov sa zobrazí Rozhodnutie o prijatí je vyrobené. Toto sa tiež nazýva Rozhodnutie Go / No-Go . Ak sú používatelia spokojní, je to go, inak je to no-go.
Dosiahnutie rozhodnutia o prijatí je zvyčajne koncom tejto fázy.
Nástroje a metodiky
Typický typ softvérových nástrojov, ktoré sa používajú počas tejto testovacej fázy, je podobný tým, ktoré sa používajú pri vykonávaní funkčného testovania.
Nástroje:
Pretože táto fáza zahŕňa validáciu úplných tokov aplikácie medzi koncovými bodmi, môže byť ťažké mať jeden nástroj na úplnú automatizáciu tejto validácie. Do istej miery by sme však boli schopní využiť automatizované skripty vyvinuté počas testovania systému.
Podobne ako pri testovaní systému, používatelia by tiež používali nástroj na správu testov a správu defektov, ako sú QC, JIRA atď. Tieto nástroje je možné nakonfigurovať tak, aby kumulovali údaje pre fázu prijímania používateľov.
Metodiky:
Aj keď konvenčné metodiky, ako sú konkrétni firemní používatelia vykonávajúci UAT produktu, sú stále relevantné, v skutočne globálnom svete, ako je ten dnešný, musí testovanie prijatia používateľa niekedy zahŕňať rôznych zákazníkov v rôznych krajinách založených na produkte.
Napríklad, webová stránka elektronického obchodu by bola používaná zákazníkmi po celom svete. V scenároch, ako je tento, by bolo najlepším riešením testovanie davu.
Davové testovanie je metodika, pri ktorej sa môžu ľudia z celého sveta zúčastňovať a overovať používanie produktu a poskytovať návrhy a odporúčania.
Platformy na testovanie davu sú postavené a v súčasnosti ich využíva veľa organizácií. Na platforme je hostená webová stránka alebo produkt, ktorý je potrebné podrobiť testu, a zákazníci sa môžu nominovať na vykonanie overenia. Poskytnuté spätné väzby sa potom analyzujú a uprednostňujú.
Metodika testovania davom sa ukazuje ako efektívnejšia, pretože pulz zákazníka na celom svete je ľahko pochopiteľný.
UAT v agilnom prostredí
Agilné prostredie má dynamickejšiu povahu. V svižnom svete budú do projektových šprintov zapojení obchodní používatelia a projekt bude vylepšený na základe spätnej väzby od nich.
Na začiatku projektu by boli obchodní používatelia kľúčovými zúčastnenými stranami, ktoré by poskytli požiadavku, a tým aktualizovali nevybavené produkty. Na konci každého sprintu sa firemní používatelia zúčastnili ukážky sprintu a boli by k dispozícii na poskytnutie spätnej väzby.
Pred dokončením šprintu by sa navyše plánovala fáza UAT, kde by obchodní používatelia robili svoje overenia.
Spätné väzby, ktoré sa prijímajú počas ukážok sprintu a sprintu UAT, sa zhromažďujú a pridávajú späť do nevybaveného produktu, ktorý sa neustále kontroluje a uprednostňuje. V agilnom svete sú teda obchodní používatelia bližšie k projektu a hodnotia to isté pre jeho použitie častejšie, na rozdiel od tradičných projektov vodopádov.
c ++ náhodné číslo medzi 1 a 3
Tím UAT - Úlohy a zodpovednosti
Typická organizácia UAT by mala nasledujúce úlohy a zodpovednosti. Tím UAT by na základe ich potrieb podporoval projektový manažér, vývojové a testovacie tímy.
Úlohy | Zodpovednosti | Výsledky |
---|---|---|
Manažér obchodného programu | • Vytvorte a udržujte plán doručenia programu • Skontrolovať a schváliť testovaciu stratégiu a plán UAT • Zaistite úspešné dokončenie programu podľa harmonogramu a rozpočtu • Spojte sa s manažérom programu IT a sledujte priebeh programu • Úzko spolupracujte s obchodným operačným tímom a vybavte ich na prevádzku 1. dňa • Dokument o podpísaní obchodnej požiadavky • Prezrite si obsah e-learningového kurzu | • Správa o pokroku programu • Týždenná správa o stave |
Manažér testov UAT | • Krétska stratégia UAT • Zaistite efektívnu spoluprácu medzi IT a Business BA a PMO • Zúčastnite sa podrobných stretnutí s požiadavkami • Skontrolujte odhad úsilia, plán testov • Zaistite sledovateľnosť požiadaviek • Podpora zhromažďovania metrík na kvantifikáciu výhod vyplývajúcich z aktualizovanej metodiky testovania, nástrojov a využitia prostredia | • Stratégia hlavného testu • Skontrolujte a schválte testovacie scenáre • Skontrolujte a schválte testovacie prípady • Skontrolujte a schválte maticu sledovateľnosti požiadaviek • Týždenná správa o stave |
Vedúci a tím testov UAT | • Overiť a overiť obchodné požiadavky oproti obchodnému procesu • Odhad pre UAT • Vytvorte a vykonajte testovací plán UAT • Zúčastnite sa požiadavky JAD • Pripravte testovacie scenáre, testovacie prípady a testovacie údaje na základe obchodného procesu • Udržiavajte sledovateľnosť • Vykonajte testovacie prípady a pripravte testovacie protokoly • Hlásiť chyby v nástroji na správu testov a spravovať ich počas celého ich životného cyklu • Vyrobiť UAT Koniec správy o teste • Poskytnite podporu pripravenosti na podnikanie a živé testovanie | • Testovací denník • Týždenná správa o stave • Správa o chybe • Metriky vykonania testu • Súhrnná správa o teste • Archivované opakovane použiteľné testovacie artefakty |
7 výziev UAT a plán zmierňovania
Nezáleží na tom, či ste súčasťou miliardového vydania alebo startupového tímu, mali by ste prekonať všetky tieto výzvy, aby ste koncovému používateľovi priniesli úspešný softvér.
# 1) Proces nastavenia a nasadenia prostredia:
Vykonanie tohto testu v rovnakom prostredí, aké používa tím funkčných testov, určite skončí prehliadnutím skutočných prípadov použitia. Zásadné testovacie činnosti, ako je testovanie výkonu, tiež nemožno vykonať v neúplnom testovacom prostredí údaje z testu .
Pre tento test by sa malo vytvoriť samostatné výrobné prostredie.
Po oddelení prostredia UAT od testovacieho prostredia musíte efektívne riadiť cyklus uvoľňovania. Nekontrolovaný cyklus uvoľňovania môže viesť k rôznym verziám softvéru v testovacom a UAT prostredí. Ak softvér nie je testovaný na najnovšej verzii, stráca sa drahocenný čas prijímacieho testu.
Medzitým je čas potrebný na sledovanie problémov pri nesprávnej verzii softvéru vysoký.
# 2) Plánovanie testu:
Toto testovanie by malo byť naplánované s jasným plánom akceptačných testov vo fáze analýzy požiadaviek a návrhu.
Pri plánovaní stratégie by sa mal na vykonanie identifikovať súbor prípadov použitia v reálnom svete. Je veľmi dôležité definovať ciele testovania pre toto testovanie, pretože pre veľké aplikácie nie je v tejto testovacej fáze možné úplné vykonanie testu. Testovanie by sa malo vykonávať najskôr stanovením priorít kritických obchodných cieľov.
Toto testovanie sa vykonáva na konci testovacieho cyklu. Je zrejmé, že je to najdôležitejšie obdobie pre vydanie softvéru. Oneskorenie v ktorejkoľvek z predchádzajúcich fáz vývoja a testovania pohltí čas UAT.
Nesprávne plánovanie testu vedie v najhorších prípadoch k prekrývaniu medzi testovaním systému a UAT. Z dôvodu kratšieho času a tlaku na dodržanie termínov je softvér nasadený do tohto prostredia, aj keď funkčné testovanie nie je dokončené. Základné ciele tohto testovania nemožno v takýchto situáciách dosiahnuť.
Plán testov UAT by mal byť pripravený a oznámený tímu dostatočne pred začiatkom tohto testu. To im pomôže pri plánovaní testov, písaní testovacích prípadov a testovacích skriptov a vytváraní prostredia UAT.
# 3) Riešenie nových obchodných požiadaviek ako incidenty / chyby:
Nejasnosti v požiadavkách sa zachytávajú vo fáze UAT. Testéri UAT nájdu problémy spôsobené nejednoznačnými požiadavkami (pri pohľade na úplné používateľské rozhranie, ktoré nebolo k dispozícii počas fázy zhromažďovania požiadaviek) a zaznamenajú ho ako chybu.
Zákazník očakáva, že tieto budú v aktuálnom vydaní opravené bez ohľadu na čas potrebný na vykonanie zmien. Ak vedenie projektu neprijme včasné rozhodnutie o týchto zmenách na poslednú chvíľu, mohlo by to viesť k zlyhaniu vydania.
# 4) Nekvalifikovaní testeri alebo testeri bez obchodných znalostí:
Ak neexistuje stály tím, spoločnosť vyberie zamestnancov UAT z rôznych interných oddelení.
Aj keď zamestnanci dobre poznajú obchodné potreby alebo nie sú vyškolení na vyvíjané nové požiadavky, nemôžu vykonávať efektívny UAT. Netechnický obchodný tím môže pri vykonávaní testovacích prípadov čeliť mnohým technickým ťažkostiam.
Priradenie testerov na konci cyklu UAT medzitým neprináša projektu žiadnu hodnotu. Málo času na školenie personálu UAT môže výrazne zvýšiť šance na úspech UAT.
# 5) Nesprávny komunikačný kanál:
otázky týkajúce sa manuálneho testovania po dobu 4 rokov
Komunikácia medzi tímom vzdialeného vývoja, testovania a UAT je náročnejšia. E-mailová komunikácia je často veľmi ťažká, ak máte offshore technologický tím. Malá nejasnosť v správach o udalostiach môže jeho opravu o jeden deň oddialiť.
Správne plánovanie a efektívna komunikácia sú rozhodujúce pre efektívnu tímovú spoluprácu. Projektové tímy by mali používať webový nástroj na zaznamenávanie chýb a otázok. Pomôže to rovnomerne rozložiť pracovné zaťaženie a zabrániť hláseniu duplicitných problémov.
# 6) Požiadanie funkčného testovacieho tímu o vykonanie tohto testovania:
Nie je horšia situácia, ako požiadať tím funkčných testov o vykonanie UAT.
Zákazníci znižujú svoju zodpovednosť voči testovaciemu tímu z dôvodu nedostatku zdrojov. Celý účel tohto testovania bude v takýchto prípadoch narušený. Po spustení softvéru koncoví používatelia rýchlo odhalia problémy, ktoré testéri funkčnosti nepovažujú za skutočné scenáre.
Riešením je priradiť toto testovanie špecializovaným a kvalifikovaným testerom, ktorí majú obchodné znalosti.
# 7) Hra za vinu
Podnikoví používatelia sa niekedy pokúšajú nájsť dôvody na odmietnutie softvéru. Môže to byť ich autizmus, aby ukázali, akí sú nadriadení, alebo obviňujú vývojový a testovací tím, aby si získal rešpekt v obchodnom tíme. Je to veľmi zriedkavé, ale stáva sa to v tímoch s vnútornou politikou.
Je veľmi ťažké zvládnuť takéto situácie. Budovanie pozitívneho vzťahu s obchodným tímom by však určite pomohlo vyhnúť sa hre na vine.
Dúfam, že vám tieto pokyny určite pomôžu splniť úspešný plán prijatia používateľov prekonaním rôznych výziev. Správne plánovanie, komunikácia, realizácia a motivovaný tím sú kľúčom k úspešnému testovaniu na prijatie používateľom.
Testovanie systému vs. Testovanie prijatia používateľa
Zapojenie testovacieho tímu začína pomerne skoro v projekte hneď od fázy analýzy požiadaviek.
Počas celého životného cyklu projektu sa pre projekt vykonáva určitá validácia, t.j. Statické testovanie , Testovanie jednotiek, Testovanie systému, Testovanie integrácie, Testovanie typu end to end alebo Regresné testovanie. To nám umožňuje lepšie pochopiť testovanie vykonané vo fáze UAT a to, ako sa líši od ostatných testovaní vykonaných predtým.
Aj keď vidíme rozdiely v SIT a UAT, je dôležité, aby sme využívali synergie, ale stále si udržiavali nezávislosť medzi oboma fázami, čo by umožnilo rýchlejší čas uvedenia na trh.
Záver
# 1) UAT nie je o stránkach, poliach alebo tlačidlách. Podkladové predpoklad ešte pred začiatkom tohto testu je to, že všetky základné veci sú testované a fungujú dobre. Preboha, používateľom sa zdá chyba tak základná - pre tím QA je to veľmi zlá správa. :(
#dva) Toto testovanie sa týka entity, ktorá je primárnym prvkom v podnikaní.
Uvediem príklad: Ak je AUT systém cestovných lístkov, UAT nebude o hľadaní ponuky, ktorá otvorí stránku, atď. Jedná sa o letenky a ich rezerváciu, štáty, ktoré môže absolvovať, cestu cez systém, atď.
Ďalší Príklad, ak je web stránkou predajcov automobilov, zameriava sa na „auto a jeho predaj“, a nie na web. Preto je hlavnou činnosťou to, čo sa overuje a validuje a kto je na to lepší ako vlastníci firmy. Preto má toto testovanie najväčší zmysel, keď je do veľkej miery zapojený zákazník.
# 3) UAT je vo svojom jadre tiež formou testovania, čo znamená že existuje veľká šanca na identifikáciu niektorých chýb aj v tejto fáze . Stáva sa to niekedy. Okrem toho, že sa jedná o veľkú eskaláciu tímu QA, chyby UAT zvyčajne znamenajú stretnutie na sedenie a diskusiu o tom, ako s nimi zaobchádzať. Po vykonaní tohto testovania zvyčajne nie je čas na opravu a opätovné testovanie.
Rozhodnutie by bolo buď:
- Posuňte dátum uvedenia do života, najskôr problém vyriešte a potom pokračujte.
- Plošticu nechajte tak, ako je.
- Považujte to za súčasť požiadavky na zmenu pre budúce vydania.
# 4) UAT je klasifikovaný ako testovanie verzie Alpha a Beta, ale táto klasifikácia nie je taká dôležitá v kontexte typických projektov vývoja softvéru v priemysle založenom na službách.
- Alfa testovanie je, keď sa UAT vykonáva v prostredí softvérového tvorcu, a je významnejší v kontexte komerčného bežného softvéru.
- Beta testovanie je, keď sa UAT vykonáva v produkčnom prostredí alebo v prostredí klienta. Toto je bežnejšie pre aplikácie orientované na zákazníka. Používatelia tu sú skutočnými zákazníkmi, ako ste vy a ja v tejto súvislosti.
# 5) Väčšinu času v bežnom projekte vývoja softvéru UAT vykonáva v QA prostredie ak neexistuje pracovné prostredie alebo prostredie UAT.
V skratke, najlepší spôsob, ako zistiť, či je váš produkt prijateľný a vhodný na daný účel, je skutočne ho postaviť pred používateľov.
Organizácie sa dostávajú do agilného spôsobu poskytovania, obchodní používatelia sa viac zapájajú a projekty sa vylepšujú a dodávajú prostredníctvom spätnej väzby. Fáza prijímania používateľov sa považuje za bránu do procesu implementácie a výroby.
Aká bola vaša skúsenosť s UAT? Boli ste v pohotovostnom režime alebo ste testovali svojich používateľov? Našli používatelia nejaké problémy? Ak áno, ako ste s nimi naložili?
=> Prečítajte si tiež VŠETKY návody z tejto série
=> Celý seminár s kompletným plánom testovacieho plánu nájdete tu
Odporúčané čítanie
- Alfa testovanie a beta testovanie (kompletný sprievodca)
- Čo je to Acceptance Testing (kompletný sprievodca)
- Kompletný sprievodca zostavením Verification Testing (BVT Testing)
- Funkčné testovanie vs. Nefunkčné testovanie
- Najlepšie nástroje na testovanie softvéru 2021 (QA Test Automation Tools)
- Typy testovania softvéru: Rôzne typy testovania s podrobnosťami
- Výukový program na testovanie dátových skladov ETL (kompletný sprievodca)
- Výukový program na testovanie grafického používateľského rozhrania: Kompletný sprievodca testovaním používateľského rozhrania (UI)