Hvad er test af brugeraccept (UAT): En komplet guide

what is user acceptance testing

Lær hvad der er brugeracceptstest (UAT) sammen med dens definition, typer, trin og eksempler:

Min regel nummer et, når jeg prøver at forstå et nyt koncept, er at: navnet vil altid være relevant og for det meste en bogstavelig betydning (i den tekniske sammenhæng).

At finde ud af hvad det er, vil give en indledende forståelse af det og hjælpe mig med at komme i gang med.

apps, der giver dig mulighed for at downloade youtube-videoer

=> Klik her for en komplet testplan-tutorial-serie

Lad os sætte dette koncept på prøve.

=> Læs alle vejledninger i vores Acceptance Testing-serie.

Hvad du lærer:

• Hvad er test af brugeraccept?
  • Hvornår udføres det?
  • Hvem udfører UAT?
  • Behov for test af brugeraccept
  • Testproces for brugeraccept
  • UAT Governance
  • UAT testplanlægning
  • Design af test af brugeraccept
  • Testudførelse
  • Værktøjer og metoder
  • UAT i agilt miljø
  • UAT Team - Roller og ansvar
• 7 udfordringer ved UAT og afbødningsplan
• Systemtestning mod test af brugeraccept
• Konklusion
  • Anbefalet læsning

Hvad er test af brugeraccept?

Vi ved, hvad testning er, accept betyder godkendelse eller aftale. Brugeren i forbindelse med et softwareprodukt er enten forbrugeren af ​​softwaren eller den person, der har anmodet om, at det bygges til ham / hende (klient).

Så efter min regel - vil definitionen være:

User Acceptance Testing (UAT), også kendt som beta- eller slutbrugertest, defineres som test af softwaren af ​​brugeren eller klienten for at afgøre, om den kan accepteres eller ej. Dette er den endelige test, der udføres, når funktionel, system- og regressionstest er afsluttet.

Hovedformålet med denne test er at validere softwaren i forhold til forretningskravene. Denne validering udføres af slutbrugerne, der er fortrolige med forretningskravene.

UAT, alfa- og beta-test er forskellige typer accept test.

Da brugeracceptstesten er den sidste test, der udføres, før softwaren sættes i live, er dette naturligvis den sidste chance for kunden at teste softwaren og måle, om den er egnet til formålet.

Hvornår udføres det?

Dette er typisk det sidste trin, inden produktet tages i brug, eller inden levering af produktet accepteres. Dette udføres efter selve produktet er grundigt testet (dvs. efter systemtest ).

Hvem udfører UAT?

Brugere eller klienter - Dette kan enten være en person, der køber et produkt (i tilfælde af kommerciel software) eller nogen, der har fået en software specialbygget gennem en softwaretjenesteudbyder eller slutbrugeren, hvis softwaren stilles til rådighed for dem forud for tiden, og når deres feedback søges.

Holdet kan bestå af betatestere, eller kunden skal vælge UAT-medlemmer internt fra hver gruppe i organisationen, så hver brugerrolle kan testes i overensstemmelse hermed.

Behov for test af brugeraccept

Udviklere og funktionstestere er tekniske personer, der validerer softwaren mod funktionelle specifikationer . De fortolker kravene i henhold til deres viden og udvikler / tester softwaren (her er vigtigheden af ​​domæne viden).

Denne software er komplet i henhold til de funktionelle specifikationer, men der er nogle forretningskrav, og processer, som kun er kendt af slutbrugerne, er enten savnet til at kommunikere eller fejlagtigt.

Denne test spiller en vigtig rolle i valideringen, hvis alle forretningskravene er opfyldt eller ikke, inden softwaren frigives til markedsbrug. Brugen af ​​live data og sager om reel brug gør denne testning til en vigtig del af frigivelsescyklussen.

Mange virksomheder, der har lidt store tab på grund af problemer efter frigivelse, kender vigtigheden af ​​en vellykket test af brugeraccept. Omkostningerne ved at rette manglerne efter frigivelse er mange gange større end at rette dem før.

Er UAT virkelig nødvendigt?

Efter at have udført masser af system-, integrations- og regressionstest ville man undre sig over nødvendigheden af ​​denne test. Faktisk er dette den vigtigste fase af projektet, da dette er det tidspunkt, hvor de brugere, der rent faktisk skal bruge systemet, ville validere systemet, så det passer til formålet.

UAT er en testfase, der i vid udstrækning afhænger af slutbrugernes perspektiv og domæne viden for en afdeling, der repræsenterer slutbrugerne.

Faktisk ville det virkelig være nyttigt for forretningsteamene, hvis de var involveret i projektet ganske tidligt, så de kan give deres synspunkter og bidrag, der kan hjælpe med effektiv anvendelse af systemet i den virkelige verden.

Testproces for brugeraccept

Den nemmeste måde at forstå denne proces på er at tænke på dette som et autonomt testprojekt - hvilket betyder, at det vil have plan-, design- og udførelsesfaserne.

Følgende er forudsætningerne, inden planlægningsfasen begynder:

# 1) Saml de vigtigste acceptkriterier

Enkelt sagt er acceptskriterier en liste over ting, der vil blive evalueret, inden de accepterer produktet.

Disse kan være af to typer:

(i) Applikationsfunktionalitet eller forretningsrelateret

Ideelt set skulle alle de vigtige forretningsfunktioner blive valideret, men på grund af forskellige årsager, herunder tid, er det ikke praktisk at gøre det hele. Derfor kan et møde eller to med klienten eller brugerne, der vil være involveret i denne test, give os en idé om, hvor meget test der skal involveres, og hvilke aspekter der skal testes.

(ii) Kontraktuel - Vi vil ikke gå ind på dette, og inddragelsen af ​​QA-teamet i alt dette er næsten ingenting. Den oprindelige kontrakt, der bliver udarbejdet, selv før SDLC begynder, gennemgås, og der opnås enighed om, hvorvidt alle aspekter af kontrakten er leveret eller ej.

Vi vil kun fokusere på applikationsfunktionaliteten.

# 2) Definer omfanget af QA-involvering.

QA-holdets rolle er en af ​​følgende:

(i) Ingen involvering - Dette er meget sjældent.

(ii) Hjælp med denne test - Mest almindelig. I dette tilfælde kan vores engagement være at træne UAT-brugerne i, hvordan de bruger applikationen og være i standby under denne test for at sikre, at vi kan hjælpe brugerne i tilfælde af problemer. Eller i nogle tilfælde udover at være i standby og hjælpe, kan vi også dele deres svar og registrere resultaterne eller logfejl osv., Mens brugerne udfører den faktiske test.

(iii) Udfør UAT og nuværende resultater - Hvis dette er tilfældet, vil brugerne pege på de områder af AUT, som de vil evaluere, og selve evalueringen udføres af QA-teamet. Når det er gjort, præsenteres resultaterne for klienter / brugere, og de vil træffe en beslutning om, hvorvidt de resultater, de har i hånden, er tilstrækkelige eller ikke og i overensstemmelse med deres forventninger for at acceptere AUT. Beslutningen er aldrig QA-holdets.

Afhængigt af den aktuelle sag beslutter vi, hvilken tilgang der er bedst.

De primære mål og forventninger:

Normalt foretages UAT af en emneekspert (SME) og / eller en forretningsbruger, som muligvis er ejer eller kunde af et testet system. I lighed med systemtestfasen omfatter UAT-fasen også religiøse faser, før den bringes til lukning.

Nøgleaktiviteter i hver UAT-fase er defineret nedenfor:

UAT Governance

I lighed med systemtest håndhæves effektiv styring for UAT for at sikre, at porte af stærk kvalitet sammen med de definerede indgangs- og udgangskriterier (angivet nedenfor **).

** Bemærk, at det kun er en vejledning. Dette kan ændres ud fra projektets behov og krav.

UAT testplanlægning

Processen er næsten den samme som med regelmæssig testplan i systemfasen.

Den mest almindelige tilgang, der følges i de fleste projekter, er at planlægge både system- og UAT-testfaser sammen. For mere information om UAT-testplanen sammen med en prøve, se venligst det vedhæftede testplandokuments UAT-sektioner.

Testplan for brugeraccept

(Dette er det samme som du også finder på vores side til QA-træningsserien).

Klik på nedenstående billede, og rul ned for at finde testplanens dokumenteksempel i forskellige formater. I denne skabelon skal du kontrollere UAT-sektionen.

Datoer, miljø, aktører (hvem), kommunikationsprotokoller, roller og ansvar, skabeloner, resultater og deres analyseproces, indgangs- / udgangskriterier - alt dette og alt andet, der er relevant, findes i UAT-testplanen.

Uanset om QA-teamet deltager, deltager delvist eller slet ikke deltager i denne test, er det vores job at planlægge denne fase og sørge for, at alt tages i betragtning.

=> Her er et prøveeksemplet med en brugeraccept testplan

Design af test af brugeraccept

De indsamlede acceptkriterier fra brugerne bruges i dette trin. Prøver kan se ud som vist nedenfor.

(Dette er uddrag fra CSTE CBOK . Dette er en af ​​de bedste referencer, der er tilgængelige om denne test.)

Skabelon til test af brugeraccept:

Baseret på kriterierne giver vi (QA-teamet) dem brugerne en liste over UAT-testsager. Disse testtilfælde adskiller sig ikke fra vores almindelige systemtesttilfælde. De er kun en delmængde, da vi tester alle applikationerne i modsætning til bare de vigtigste funktionelle områder.

Ud over disse skal data, skabeloner til registrering af testresultater, administrative procedurer, fejlloggingmekanisme osv. Være på plads, før vi går videre til næste fase.

Testudførelse

Normalt, når det er muligt, sker denne testning i en konference eller i et krigsrum som en opsætning, hvor brugerne, PM, QA-teamrepræsentanter alle sidder sammen en dag eller to og arbejder igennem alle accepttestsagerne.

Eller hvis QA-teamet udfører testene, kører vi testsagerne på AUT.

Når alle testene er kørt, og resultaterne er i hånden, Acceptbeslutning er lavet. Dette kaldes også Go / No-Go-beslutning . Hvis brugerne er tilfredse, er det en Go, ellers er det en No-go.

At nå acceptbeslutningen er typisk afslutningen på denne fase.

Værktøjer og metoder

Typisk svarer typen af ​​softwareværktøjer, der bruges i denne testfase, til de værktøjer, der anvendes under udførelse af funktionel test.

Værktøjer:

hvordan man laver liste i java

Da denne fase involverer validering af programmets komplette slut-til-slut-strømme, kan det være svært at have et værktøj til at automatisere denne validering fuldstændigt. Imidlertid vil vi til en vis grad kunne udnytte de automatiske scripts, der er udviklet under systemtest.

I lighed med systemtest bruger brugerne også teststyrings- og defektstyringsværktøj som QC, JIRA osv. Disse værktøjer kan konfigureres til at kumulere data til brugeracceptfasen.

Metoder:

Selvom konventionelle metoder, såsom specifikke forretningsbrugere, der udfører UAT af produktet, stadig er relevante, i en virkelig global verden som i dag, skal brugertestningstest undertiden involvere forskellige kunder på tværs af lande baseret på produktet.

For eksempel, en e-handelswebsite ville blive brugt af kunder over hele kloden. I scenarier som dette ville crowdtest være den bedste løsning.

Crowd-test er en metode, hvor folk fra hele verden kan deltage og validere brugen af ​​produktet og give forslag og anbefalinger.

Crowdtestplatforme er bygget og bruges af mange organisationer nu. Et websted eller et produkt, der skal crowd-testes, hostes på platformen, og kunderne kan indstille sig til at foretage valideringen. De tilbagemeldinger, der gives, analyseres og prioriteres derefter.

Crowd Testing-metode viser sig at være mere effektiv, da kundens puls over hele kloden let kan forstås.

UAT i agilt miljø

Det smidige miljø er mere dynamisk. I en agil verden vil forretningsbrugere blive involveret i hele projektsprinten, og projektet vil blive forbedret baseret på feedback-sløjferne fra dem.

I begyndelsen af ​​projektet ville forretningsbrugere være de vigtigste interessenter til at stille krav og derved opdatere produktets efterslæb. I slutningen af ​​hver sprint ville forretningsbrugere deltage i sprintdemoen og ville være tilgængelige for at give feedback.

Desuden ville en UAT-fase planlægges inden sprintafslutningen, hvor forretningsbrugere ville gøre deres valideringer.

De tilbagemeldinger, der modtages under sprintdemo og sprint UAT, samles og føjes tilbage til produktets efterslæb, der konstant gennemgås og prioriteres. Således i en agil verden er forretningsbrugere tættere på projektet, og de vurderer det samme for dets anvendelse oftere i modsætning til de traditionelle vandfaldsprojekter.

UAT Team - Roller og ansvar

En typisk UAT-organisation vil have følgende roller og ansvar. UAT-teamet blev støttet af projektlederen, udviklings- og testteamene baseret på deres behov.

7 udfordringer ved UAT og afbødningsplan

Det betyder ikke noget, om du er en del af en frigivelse på en milliard dollar eller et opstartteam, skal du overvinde alle disse udfordringer for at levere vellykket software til slutbrugeren.

# 1) Opsætning af miljø og implementeringsproces:

At udføre denne test i det samme miljø, som det funktionelle testteam bruger, vil helt sikkert ende med at overse de virkelige brugssager. Desuden kan vigtige testaktiviteter som præstationstest ikke udføres i et testmiljø, der er ufuldstændigt testdata .

Der skal oprettes et separat produktionslignende miljø til denne test.

Når UAT-miljøet er adskilt fra testmiljøet, skal du kontrollere frigivelsescyklussen effektivt. Ukontrolleret frigivelsescyklus kan føre til forskellige softwareversioner i test- og UAT-miljø. Værdifuld accepttesttid spildes, når softwaren ikke testes i den nyeste version.

I mellemtiden er den tid, der kræves til problemsporing på forkert softwareversion, høj.

# 2) Testplanlægning:

Denne testning skal planlægges med en klar accepttestplan i kravanalysen og designfasen.

I strategiplanlægning skal sættet af virkelige brugssager identificeres til udførelse. Det er meget vigtigt at definere testmålene for denne test, da en komplet testudførelse ikke er mulig for store applikationer i denne testfase. Testning skal udføres ved først at prioritere kritiske forretningsmål.

Denne test udføres i slutningen af ​​testcyklussen. Det er åbenbart, at det er den mest kritiske periode for softwareudgivelsen. Forsinkelse i et hvilket som helst af de foregående stadier af udvikling og test spiser UAT-tiden.

Forkert testplanlægning fører i værste tilfælde til en overlapning mellem systemtesten og UAT. På grund af mindre tid og pres for at overholde deadlines, implementeres softwaren i dette miljø, selvom funktionel test ikke er afsluttet. De vigtigste mål for denne test kan ikke nås i sådanne situationer.

UAT-testplanen skal udarbejdes og meddeles holdet i god tid inden denne test påbegyndes. Dette hjælper dem med testplanlægning, skrivning af testcases & testskripter og oprettelse af et UAT-miljø.

# 3) Håndtering af nye forretningskrav som hændelser / mangler:

Uklarheder i kravene bliver fanget i UAT-fasen. UAT-testere finder problemer, der opstår på grund af tvetydige krav (ved at se på den komplette brugergrænseflade, som ikke var tilgængelig under kravindsamlingsfasen) og logge den som en defekt.

Kunden forventer, at disse rettes i den aktuelle frigivelse uden at overveje tidspunktet for ændringsanmodningerne. Hvis projektledelsen ikke træffer en rettidig beslutning om disse ændringer i sidste øjeblik, kan dette føre til frigivelsesfejl.

# 4) Uuddannede testere eller testere uden forretningskendskab:

Når der ikke er noget fast team, vælger virksomheden UAT-personale fra forskellige interne afdelinger.

Selvom personalet er fortrolig med forretningsbehovene, eller hvis de ikke er uddannet til de nye krav, der udvikles, kan de ikke udføre effektiv UAT. Et ikke-teknisk forretningsteam kan også have mange tekniske problemer med at udføre testsagerne.

I mellemtiden tilføjer tildelingen af ​​testere i slutningen af ​​UAT-cyklussen ingen værdi til projektet. Lidt tid til at træne UAT-medarbejderne kan øge chancerne for UAT-succes betydeligt.

# 5) Forkert kommunikationskanal:

Kommunikation mellem fjernudvikling, test og UAT-team er vanskeligere. E-mail-kommunikation er ofte meget vanskelig, når du har et offshore tech-team. En lille tvetydighed i hændelsesrapporter kan forsinke rettelsen i en dag.

Korrekt planlægning og effektiv kommunikation er afgørende for effektivt teamsamarbejde. Projektgrupper skal bruge et webbaseret værktøj til at logge fejl og spørgsmål. Dette hjælper med at fordele arbejdsbyrden jævnt og undgå at rapportere duplikatproblemer.

# 6) At bede funktionelt testteam om at udføre denne test:

Der er ingen værre situation end at bede det funktionelle testteam om at udføre UAT.

Kunder aflæsser deres ansvar over for testteamet på grund af mangel på ressourcer. Hele formålet med denne test bliver kompromitteret i sådanne tilfælde. Når softwaren er gået i live, vil slutbrugerne hurtigt få øje på de problemer, der ikke betragtes som virkelige scenarier af de funktionelle testere.

En løsning på dette er at tildele denne test til de dedikerede og dygtige testere, der har forretningskendskab.

# 7) Skyldespillet

Nogle gange forsøger forretningsbrugere bare at finde grunde til at afvise softwaren. Det kan være deres selvdom at vise, hvor overlegne de er eller bebrejde udviklings- og testteamet for at få respekt i forretningsteamet. Dette er meget sjældent, men sker i hold med intern politik.

Det er meget vanskeligt at håndtere sådanne situationer. At opbygge et positivt forhold til forretningsteamet vil dog helt sikkert hjælpe med at undgå skyldspelet.

Jeg håber, at disse retningslinjer helt sikkert vil hjælpe dig med at gennemføre en vellykket brugeracceptplan ved at overvinde forskellige udfordringer. Korrekt planlægning, kommunikation, udførelse og motiveret team er nøglerne til vellykket test af brugeraccept.

Systemtestning mod test af brugeraccept

Inddragelsen af ​​testteamet starter ganske tidligt i projektet lige fra kravanalysefasen.

Gennem hele projektets livscyklus udføres en form for validering for projektet, dvs. Statisk test , Enhedstest, Systemtest, integrationstest, test til ende til slut eller regressionstest. Dette efterlader os til at forstå bedre om den test, der er udført i UAT-fasen, og hvor forskellig den er fra den anden test, der blev udført tidligere.

Selvom vi ser forskellene i SIT og UAT, er det vigtigt, at vi udnytter synergier, men stadig opretholder uafhængigheden mellem begge faser, hvilket muliggør hurtigere markedsføringstid.

Konklusion

# 1) UAT handler ikke om sider, felter eller knapper. Det underliggende antagelse selv før denne test begynder, er, at alt det grundlæggende er testet og fungerer fint. Gud forbyde, brugerne finder en fejl så grundlæggende som den - det er et stykke meget dårlige nyheder for QA-teamet. :(

#to) Denne test handler om den enhed, der er det primære element i virksomheden.

Lad mig give dig et eksempel: Hvis AUT er et billetsystem, vil UAT ikke handle om, søge efter den menu, der åbner en side osv. Det handler om billetterne og deres reservation, de stater, det kan tage, sin rejse gennem systemet, etc.

En anden Eksempel, hvis webstedet er et bilforhandlersted, så er fokus på 'bilen og dens salg' og ikke rigtig webstedet. Derfor er kerneforretningen, hvad der er verificeret og valideret, og hvem der er bedre til at gøre det end virksomhedsejerne. Derfor giver denne test mest mening, når kunden i høj grad er involveret.

# 3) UAT er også en form for test i sin kerne, hvilket betyder at der også er en god chance for at identificere nogle bugs i denne fase . Det sker nogle gange. Bortset fra det faktum, at det er en stor optrapning på QA-teamet, betyder UAT-bugs normalt et møde for at sidde og diskutere, hvordan man håndterer dem, da der efter denne test normalt ikke er tid til at rette og teste igen.

Beslutningen er enten at:

formørkelse ide til c / c ++

• Skub go-live-datoen, rett først problemet, og fortsæt derefter.
• Lad bugten være som den er.
• Overvej det som en del af anmodningen om ændring af fremtidige udgivelser.

# 4) UAT er klassificeret som Alpha- og Beta-test, men klassificeringen er ikke så vigtig i forbindelse med typiske softwareudviklingsprojekter i en servicebaseret industri.

• Alpha test er, når UAT udføres i softwarebyggerens miljø og er mere signifikant i forbindelse med kommerciel software fra hylden.
• Betatestning er, når UAT udføres i produktionsmiljøet eller klientens miljø. Dette er mere almindeligt for kundeorienterede applikationer. Brugerne her er de faktiske kunder som dig og mig i denne sammenhæng.

# 5) Det meste af tiden i et regelmæssigt softwareudviklingsprojekt udføres UAT i QA-miljø hvis der ikke er iscenesættelse eller UAT-miljø.

Kort sagt, den bedste måde at finde ud af, om dit produkt er acceptabelt og egnet til formålet, er at faktisk placere det foran brugerne.

Organisationer kommer ind i den smidige måde at levere på, forretningsbrugere bliver mere involverede, og projekterne forbedres og leveres via feedback-sløjfer. Når alt er gjort, betragtes brugeracceptfasen som porten til at komme i implementering og produktion.

Hvad var din UAT-oplevelse? Var du i standby, eller testede du for dine brugere? Fandt brugerne nogen problemer? Hvis ja, hvordan håndterede du dem?

=> Læs også ALLE tutorials i denne serie her

=> Besøg her for en komplet testplan-tutorial-serie

Anbefalet læsning

• Alpha-test og betatestning (En komplet guide)
• Hvad er acceptstest (En komplet guide)
• Build Verification Testing (BVT Testing) Komplet guide
• Funktionel testning mod ikke-funktionel testning
• Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
• Typer af softwaretest: Forskellige testtyper med detaljer
• ETL Testing Tutorial Data Warehouse Testing Tutorial (En komplet guide)
• GUI Testing Tutorial: A Complete User Interface (UI) Testing Guide