Co je User Acceptance Testing (UAT): Kompletní průvodce

Zjistěte, co je User Acceptance Testing (UAT) Spolu s jeho definicí, typy, kroky a příklady:

Mým pravidlem číslo jedna při pokusu o porozumění novému konceptu je, že: název bude vždy relevantní a většinou doslovný význam (v technický kontext).

Zjištění, co to je, vám dá počáteční pochopení a pomůže mi začít.

= > Klikněte sem a získejte kompletní výukové série plánů testování.

Pojďme otestovat tento koncept.

= > Přečtěte si všechny výukové programy v naší sérii Acceptance Testing.

Co je Testování přijetí uživatelem?

Víme, co je testování, přijetí znamená schválení nebo souhlas. Uživatel v kontextu softwarového produktu je buď spotřebitelem softwaru, nebo osobou, která požadovala, aby byl vytvořen pro něj (klienta).

Takže podle mého pravidla – definice bude :

Testování uživatelské přejímky (UAT), známé také jako beta nebo testování koncových uživatelů, je definováno jako testování softwaru uživatelem nebo klientem, aby se zjistilo, zda jej lze přijmout nebo ne. Toto je závěrečné testování provedené po dokončení funkčního, systémového a regresního testování.

Hlavním účelem tohoto testování je ověření softwaru podle obchodních požadavků. Toto ověřování provádějí koncoví uživatelé, kteří jsou obeznámeni s obchodními požadavky.

Testování UAT, alfa a beta jsou různé typy akceptačních testů.

Protože akceptační test uživatele je posledním testováním, které se provádí před spuštěním softwaru, jedná se samozřejmě o poslední příležitost pro zákazníka otestovat software a změřit, zda je vhodný pro daný účel.

Kdy se provádí?

Toto je obvykle poslední krok před uvedením produktu do provozu nebo před přijetím dodávky produktu. To se provádí po důkladném otestování samotného produktu (tj. Po testování systému).

Kdo provádí UAT?

Uživatelé nebo klient – Může to být někdo, kdo kupuje produkt ( v případě komerčního softwaru) nebo někdo, kdo si nechal software vytvořit na zakázku prostřednictvím poskytovatele softwarových služeb nebo koncového uživatele, pokud je jim software zpřístupněn v předstihu a když je vyhledána jejich zpětná vazba.

Tým může být složen z beta testerů nebo by si zákazník měl interně vybírat členy UAT z každé skupiny organizace, aby bylo možné příslušným způsobem otestovat každou roli uživatele.

Potřeba testování přijetí uživatele

Vývojáři a testeři funkcí jsou technici, kteří ověřují software podle funkčních specifikací. Interpretují požadavky podle svých znalostí a vyvíjejí / testují software (zde je důležitost znalostí domény).

Tento software je kompletní podle funkčních specifikací, ale existují některé obchodní požadavky a procesy, které jsou známé pouze koncovým uživatelům, buď jim chybí komunikace, nebo jsou nesprávně interpretovány.

Toto testování hraje důležitou roli při ověřování, zda jsou splněny všechny obchodní požadavky, nebo ne před vydáním softwaru pro tržní použití. Díky použití živých dat a skutečným případům použití je toto testování důležitou součástí cyklu vydání.

Mnoho podniků, které utrpěly velké ztráty kvůli problémům po vydání, ví důležitost úspěšného testu přijatelnosti uživatelů. Náklady na opravu defektů po vydání jsou mnohonásobně vyšší než jejich oprava dříve.

Je UAT opravdu nutný?

Po provedení zatížení systému, integraci a regresním testování by se člověk divil nutnost tohoto testování. Ve skutečnosti jde o nejdůležitější fázi projektu, protože to je doba, kdy uživatelé, kteří skutečně budou systém používat, ověří systém z hlediska jeho vhodnosti pro daný účel.

UAT je test fáze, která do značné míry závisí na perspektivě koncových uživatelů a doménových znalostech oddělení, které je zastupuje.

Ve skutečnosti by obchodním týmům skutečně pomohlo, kdyby do projektu byli zapojeni poměrně brzy, aby mohli poskytnout své názory a příspěvky, které by pomohly efektivnímu využití systému v reálném světě.

Proces testování přijatelnosti uživatelů

Nejjednodušší způsob, jak porozumět tomuto procesu, je myslet na něj jako na projekt autonomního testování – což znamená, že bude mít fáze plánu, návrhu a provedení.

Níže jsou uvedeny předpoklady před fází plánování začíná:

# 1) Shromážděte klíčová kritéria přijetí

Jednoduše řečeno, kritéria přijetí jsou seznamem které se před přijetím produktu nechají vyhodnotit.

Mohou to být dva typy:

(i) Funkce aplikace nebo související s podnikáním

V ideálním případě by všechny klíčové obchodní funkce měly být ověřeny, ale kvůli z různých důvodů, včetně času, není praktické dělat vše. Setkání nebo dva s klientem nebo uživateli, kteří se do tohoto testování zapojí, nám proto mohou poskytnout představu o tom, jak moc bude testování zahrnuto a jaké aspekty budou testovány.

(ii) Smluvní – nebudeme se tím zabývat a zapojení týmu QA do toho všeho je téměř nic. Počáteční smlouva, která se uzavře ještě před zahájením SDLC, je zkontrolována a je dosaženo dohody o tom, zda byly doručeny všechny aspekty smlouvy, či nikoli.

Zaměříme se pouze na funkčnost aplikace .

# 2) Definujte rozsah zapojení QA.

Role týmu QA je jednou z následujících:

(i) Žádné zapojení – to je velmi vzácné.

(ii) Pomoc při tomto testování – většina běžný. V tomto případě by mohlo být naším zapojením školení uživatelů UAT o tom, jak používat aplikaci, a být v pohotovostním režimu během tohoto testování, abychom se ujistili, že můžeme uživatelům pomoci v případě jakýchkoli potíží. Nebo v některých případech můžeme kromě toho, že jsme v pohotovostním režimu a pomáháme, sdílet jejich odpovědi a zaznamenávat výsledky nebo zaznamenávat chyby atd., Zatímco uživatelé provádějí skutečné testování.

(iii) Proveďte UAT a prezentovat Výsledky – Pokud se jedná o tento případ, uživatelé nasměrují oblasti AUT, které chtějí vyhodnotit, a samotné vyhodnocení provádí tým QA. Po dokončení jsou výsledky prezentovány klientům / uživatelům a oni se rozhodnou, zda jsou výsledky, které mají v ruce, dostatečné nebo ne a v souladu s jejich očekáváními, aby přijali AUT. Rozhodnutí nikdy není na rozhodnutí týmu QA.

V závislosti na konkrétním případu rozhodujeme, který přístup je nejlepší.

Primární cíle a očekávání:

UAT obvykle provádí Expert na předmětové záležitosti (SME) a / nebo obchodní uživatel, který může být vlastníkem nebo zákazníkem testovaného systému. Podobně jako fáze testování systému zahrnuje fáze UAT také náboženské fáze, než bude ukončena.

Klíčové aktivity každé fáze UAT jsou definovány níže:

UAT Governance

Podobně jako testování systému je pro UAT vynucováno efektivní řízení, aby bylo zajištěno, že silné brány kvality spolu s definovanými kritérii pro vstup a výstup (uvedené níže **).

** Vezměte prosím na vědomí, že se jedná o jen vodítko. To lze upravit na základě potřeb a požadavků projektu.

Plánování testů UAT

Proces je téměř stejný jako u běžného plánu testů v systémové fázi.

Nejběžnějším přístupem používaným ve většině projektů je společné plánování testovacích fází systému i UAT. Další informace o plánu testování UAT spolu se vzorkem najdete v částech dokumentu UAT přiloženého dokumentu s testovacím plánem.

Plán testování přijatelnosti uživatele

(Toto je stejné, jako byste najdete na našem webu také tréninkovou sérii QA).

Klikněte na obrázek níže a přejděte dolů a najděte ukázku dokumentu plánu testování v různých formátech. V této šabloně zkontrolujte sekci UAT.

Data, prostředí, aktéři (kdo), komunikační protokoly, role a odpovědnosti, šablony, výsledky a jejich proces analýzy, kritéria vstupu a výstupu – vše toto a cokoli dalšího, co je relevantní, najdete v plánu testu UAT.

Ať už se tým QA účastní, částečně účastní nebo neúčastní vůbec tohoto testu, je naší úlohou naplánovat tuto fázi a ujistěte se, že je vzato v úvahu vše.

= > Zde je ukázkový dokument plánu testu přijatelnosti uživatele

Návrh testování přijatelnosti uživatele

V tomto kroku se použijí shromážděná kritéria přijetí od uživatelů. Ukázky mohou vypadat níže.

(Toto jsou výňatky z CSTE CBOK. Toto je jedna z nejlepších referencí o tomto testování.)

Šablona pro testování akceptace uživatele:

Na základě kritérií jim (tým QA) poskytneme uživatelům seznam testovacích případů UAT. Tyto testovací případy se neliší od našich běžných testovacích případů systému. Jsou jen podmnožinou, protože testujeme všechny aplikace na rozdíl od klíčových funkčních oblastí.

Kromě těchto údajů, šablon pro zaznamenávání výsledků testů, administrativních postupů, mechanismu protokolování defektů, atd., musí být na místě, než přejdeme do další fáze.

Provedení testu

Obvykle, pokud je to možné, probíhá toto testování na konferenci nebo ve válečné místnosti. nastavit, kde uživatelé, PM, QA zástupci týmu všichni sedí spolu jeden nebo dva dny a pracují ve všech případech akceptačních testů.

Nebo v případě, že QA tým provádí testy, spustíme test případy na AUT.

Jakmile jsou spuštěny všechny testy a jsou k dispozici výsledky, je přijato rozhodnutí o přijetí. Toto se také nazývá rozhodnutí Go / No-Go. Pokud jsou uživatelé spokojeni, je to Go, jinak jde o No-go.

Dosažení rozhodnutí o přijetí je obvykle na konci této fáze.

Nástroje & Metodiky

Typ softwarových nástrojů, které se používají během této testovací fáze, je obvykle podobný nástrojům používaným při provádění funkčního testování.

Nástroje:

Jelikož tato fáze zahrnuje ověřování úplných toků aplikace mezi konci, může být obtížné mít jeden nástroj k úplné automatizaci tohoto ověřování. Do určité míry bychom však byli schopni využít automatizované skripty vyvinuté během testování systému.

Podobně jako testování systému by uživatelé také používali nástroj pro správu testů a správu defektů, jako je QC, JIRA atd. Tyto nástroje lze nakonfigurovat tak, aby kumulovaly data pro fázi přijetí uživatele.

Metodiky:

Ačkoli konvenční metodiky, jako jsou konkrétní obchodní uživatelé provádějící UAT produktu, jsou stále relevantní, ve skutečně globálním ve světě jako dnes musí testování přijatelnosti uživatelů někdy zahrnovat různé zákazníky napříč zeměmi podle produktu.

Například web elektronického obchodu by používali zákazníci po celém světě. V takových scénářích by bylo nejlepším řešením testování davů.

Testování davů je metodika, kde se mohou účastnit lidé z celého světa, ověřovat použití produktu a dávat návrhy a doporučení.

Platformy pro testování davů jsou vytvořeny a nyní je využíváno mnoha organizacemi. Na platformě je hostován web nebo produkt, který musí být testován davem, a zákazníci se mohou sami nominovat na ověření. Poskytnuté zpětné vazby jsou poté analyzovány a upřednostněny.

Metodika testování davu se ukazuje jako efektivnější, protože puls zákazníka po celém světě lze snadno pochopit.

UAT v agilním prostředí

Agilní prostředí má dynamičtější povahu. V agilním světě budou obchodní uživatelé zapojeni do projektových sprintů a projekt by byl vylepšen na základě zpětnovazebních smyček od nich.

Na začátku projektu by byli obchodní uživatelé klíčovými zúčastněnými stranami poskytnout požadavek a tím aktualizovat nevyřízené položky produktu. Na konci každého sprintu by se obchodní uživatelé účastnili demo sprintu a byli by k dispozici pro poskytnutí jakékoli zpětné vazby.

Navíc by byla plánována fáze UAT před dokončením sprintu, kde by si obchodní uživatelé dělali své validace.

Zpětné vazby, které jsou přijímány během ukázky sprintu a sprintu UAT, jsou shromažďovány a přidávány zpět do nevyřízeného produktu, který je neustále kontrolován a upřednostňován. V agilním světě jsou tedy firemní uživatelé blíže k projektu a hodnotí totéž pro jeho použití častěji než na rozdíl od tradičních projektů vodopádů.

UAT Team – role & Odpovědnosti

Typická organizace UAT by měla následující role a odpovědnosti. Tým UAT by na základě jejich potřeb podporoval projektový manažer, vývojové a testovací týmy.

7 výzev UAT A plán zmírnění dopadů

Nezáleží na tom, zda jste součástí vydání v hodnotě miliard dolarů nebo spouštěcím týmem, měli byste překonat všechny tyto výzvy při poskytování úspěšného softwaru pro koncového uživatele.

# 1) Proces nastavení a nasazení prostředí:

Provedení tohoto testu ve stejném prostředí, jaké používá tým funkčních testů, určitě skončí s výhledem na případy použití v reálném světě. Rozhodující testovací činnosti, jako je testování výkonu, také nelze provádět v testovacím prostředí s neúplnými testovacími daty.

Pro tento test by mělo být nastaveno samostatné produkční prostředí.

Jakmile je prostředí UAT odděleno od testovacího prostředí, musíte efektivně řídit cyklus vydání. Cyklus nekontrolovaného vydání může vést k různým verzím softwaru v testovacím a UAT prostředí. Pokud software není testován na nejnovější verzi, zbytečně se ztrácí čas na přijatelný testovací test.

Mezitím je čas potřebný pro sledování problémů s nesprávnou verzí softwaru vysoký.

# 2) Test Plánování:

Toto testování by mělo být plánováno s jasným plánem akceptačních testů ve fázi analýzy požadavků a návrhu.

Při plánování strategie by měla být identifikována sada případů použití v reálném světě k provedení. Je velmi důležité definovat cíle testování pro toto testování, protože u velkých aplikací není v této fázi testování možné úplné provedení testu. Testování by mělo být prováděno nejprve upřednostňováním důležitých obchodních cílů.

Toto testování se provádí na konci testovacího cyklu. Je zřejmé, že je to nejdůležitější období pro vydání softwaru. Zpoždění v kterékoli z předchozích fází vývoje a testování pohltí čas UAT.

Nesprávné plánování testů v nejhorších případech vede k překrývání mezi testováním systému a UAT. Kvůli menšímu času a tlaku na dodržení termínů je software nasazen do tohoto prostředí, i když není funkční testování dokončeno. V takových situacích nelze dosáhnout základních cílů tohoto testování.

Plán testování UAT by měl být připraven a sdělen týmu včas před zahájením tohoto testu. To jim pomůže při plánování testů, psaní testovacích skriptů & testů a vytváření prostředí UAT.

# 3) Zpracování nových obchodních požadavků jako incidentů / defektů:

Nejasnosti v požadavcích se zachytí ve fázi UAT. Testeři UAT najdou problémy vzniklé kvůli nejednoznačným požadavkům (při pohledu na kompletní uživatelské rozhraní, které nebylo k dispozici během fáze shromažďování požadavků) a zaznamenají jej jako vadu.

Zákazník očekává, že budou v aktuálním vydání opraveny bez ohledu na čas potřebný ke změně. Pokud vedení projektu o těchto změnách na poslední chvíli nepřijme včasné rozhodnutí, mohlo by to vést k selhání vydání.

# 4) Nekvalifikovaní testeři nebo testeři bez obchodních znalostí:

Pokud zde není stálý tým, vybere si společnost zaměstnance UAT z různých interních oddělení.

I když zaměstnanci dobře znají obchodní potřeby nebo nejsou vyškoleni na nové požadavky, které jsou vyvíjeny, nemohou provádět efektivní UAT. Netechnický obchodní tým může při provádění testovacích případů čelit mnoha technickým obtížím.

Přiřazení testerů na konci cyklu UAT nepřináší projektu žádnou hodnotu. Málo času na zaškolení zaměstnanců UAT může významně zvýšit šance na úspěch UAT.

# 5) Nesprávný komunikační kanál:

Komunikace mezi vzdáleným vývojem, testováním a týmem UAT je obtížnější . E-mailová komunikace je často velmi obtížná, pokud máte offshore technologický tým. Malá nejednoznačnost ve zprávách o incidentech může jeho opravu o den oddálit.

Správné plánování a efektivní komunikace jsou pro efektivní týmovou spolupráci zásadní. Projektové týmy by k zaznamenávání závad a otázek měly používat webový nástroj. To pomůže rovnoměrně rozložit pracovní zátěž a vyhnout se hlášení duplicitních problémů.

# 6) Požádání funkčního testovacího týmu o provedení tohoto testování:

Není horší situace než požádat o funkční test tým vykonávat UAT.

Zákazníci snižují svoji odpovědnost vůči testovacímu týmu kvůli nedostatku zdrojů. Celý účel tohoto testování je v takových případech ohrožen. Jakmile bude software uveden do provozu, koncoví uživatelé rychle odhalí problémy, které testeři funkcí nepovažují za scénáře reálného světa.

Řešením je přiřadit toto testování specializovaným a zkušeným testeři, kteří mají obchodní znalosti.

# 7) The Blame Game

Někdy se obchodní uživatelé snaží najít důvody, proč software odmítnout. Může to být jejich autismus, aby ukázali, jak jsou nadřazení, nebo obviňují vývojový a testovací tým, aby získal respekt v obchodním týmu. To je velmi vzácné, ale stává se to v týmech s vnitřní politikou.

Je velmi obtížné takové situace řešit. Budování pozitivního vztahu s obchodním týmem by však rozhodně pomohlo vyhnout se hře obviňování.

Doufám, že vám tyto pokyny jistě pomohou uskutečnit úspěšný plán přijetí uživatelem překonáním různých výzev. Správné plánování, komunikace, provádění a motivovaný tým jsou klíčem k úspěšnému testování přijatelnosti uživateli.

Testování systému vs. Testování přijatelnosti uživatele

Zapojení testovacího týmu začíná poměrně brzy v projekt již od fáze analýzy požadavků.

Během celého životního cyklu projektu se pro projekt provádí určitý druh ověření, tj. statické testování, testování jednotky, testování systému, testování integrace, testování typu end-to-end. nebo regresní testování. To nám umožňuje lépe pochopit testování prováděné ve fázi UAT a to, jak se liší od ostatních dříve prováděných testů.

Ačkoli vidíme rozdíly v SIT a UAT, je důležité využívat synergie ale stále udržovat nezávislost mezi oběma fázemi, což by umožnilo rychlejší uvedení na trh.

Závěr

# 1) UAT není o stránkách, polích ani tlačítkách. Základní předpoklad ještě před zahájením tohoto testu je, že všechny ty základní věci jsou testovány a fungují dobře. Bohužel, uživatelé považují chybu za tak základní – pro tým QA je to velmi špatná zpráva. 🙁

# 2) Toto testování je o entitě, která je primárním prvkem v podnikání.

Dovolte mi uvést příklad: Pokud je AUT lístkový systém, UAT nebude o tom, hledat menu, které otevírá stránku atd. Jedná se o letenky a jejich rezervaci, stavy, které může vzít, jeho cestu systémem atd.

Další příklad, pokud je web autosalon, pak se pozornost zaměřuje na „auto a jeho prodej“, a nikoli na web. Proto je hlavní náplní podnikání to, co je ověřeno a ověřeno a kdo je lepší, než to udělat vlastníci firem. Proto má toto testování největší smysl, pokud je do velké míry zapojen zákazník.

# 3) UAT je také formou testování ve svém jádru, což znamená, že existuje velká šance na identifikace některých chyb i v této fázi. Občas se to stane. Kromě skutečnosti, že se jedná o zásadní eskalaci v týmu QA, chyby UAT obvykle znamenají setkání k sezení a diskusi o tom, jak s nimi zacházet následovně po ukončení tohoto testování obvykle není čas na opravu a opakované testování.

Rozhodnutí by bylo buď:

• Posuňte datum uvedení do provozu, nejprve vyřešte problém a poté pokračujte.
• Nechte chybu tak, jak je.
• Považujte to za součást požadavku na změnu pro budoucí vydání.

# 4) UAT je klasifikován jako testování Alpha a Beta, ale tato klasifikace není tak důležitá v kontextu typických projektů vývoje softwaru v odvětví založeném na službách.

• Alfa testování je, když se UAT provádí v prostředí tvůrce softwaru a je významnější v kontextu komerčních komerčních řešení. software.
• Beta testování je, když se UAT provádí v produkčním prostředí nebo v prostředí klienta. To je běžnější pro aplikace orientované na zákazníka. Uživatelé zde jsou skuteční zákazníci, jako jste vy a já v tomto kontextu.

# 5) Většinu času v běžném projektu vývoje softwaru se UAT provádí v prostředí QA, pokud existuje není žádné pracovní prostředí ani prostředí UAT.

Stručně řečeno, nejlepším způsobem, jak zjistit, zda je váš produkt přijatelný a vhodný pro daný účel, je skutečně jej předložit uživatelům.

Organizace se dostávají do agilního způsobu poskytování, obchodní uživatelé se více zapojují a projekty jsou vylepšovány a dodávány prostřednictvím smyček zpětné vazby. Po dokončení je fáze přijímání uživatelů považována za bránu pro vstup do implementace a výroby.

Jaké byly vaše zkušenosti s UAT? Byli jste v pohotovostním režimu nebo jste testovali své uživatele? Zjistili uživatelé nějaké problémy? Pokud ano, jak jste s nimi zacházeli?

= > Přečtěte si také VŠECHNY výukové programy v této sérii zde

= > Tady naleznete kompletní sérii testovacích plánů.