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

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 teknisk kontekst).

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

= > 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 er User Acceptance Testing?

Vi ved, hvad test 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 blive bygget til ham / hende (klient).

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

User Acceptance Testing (UAT), også kendt som beta- eller slutbruger-test, 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 testning 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 bruger accept test er den sidste test, der udføres inden softwaren tages i brug, er det selvfølgelig den sidste chance for kunden at teste softwaren og måle, om den er egnet til formålet.

Hvornår udføres den?

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

Hvem udfører UAT?

Brugere eller klienter – Dette kan enten være nogen, 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 inden tiden, og når deres feedback søges.

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

Behov for test af brugeraccept

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

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

Denne test spiller en vigtig rolle i validering, hvis alle forretningskravene er opfyldt eller ikke, inden softwaren frigives til markedsbrug. Brug af live data og reelle anvendelsessager gør denne testning til en vigtig del af frigivelsescyklussen.

Mange virksomheder, der har lidt store tab på grund af problemer efter frigivelsen, kender vigtigheden af en vellykket brugeracceptstest. 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 vil bruge systemet, validerer systemet, så det passer til formålet.

UAT er en test fase, 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.

Test af proces til brugeraccept

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 nøgle Acceptkriterier

Enkelt sagt er acceptskriterier en liste over disse ngs, der skal evalueres, inden de accepterer produktet.

Disse kan være af to typer:

(i) Applikationsfunktionalitet eller Forretningsrelateret

Ideelt set skulle alle de vigtigste forretningsfunktioner blive valideret, men på grund af 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 skal 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 til denne test – Mest almindelige. 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-teamets.

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, der 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 adgangs- og udgangskriterier (angivet nedenfor **).

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

UAT-testplanlægning

Processen er næsten den samme som med den almindelige 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, bedes du tjekke det vedhæftede testplandokuments UAT-sektioner.

Test af brugeraccept testplan

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

Klik på nedenstående billede, og rul ned for at finde prøveeksemplaret i testplanen i forskellige formater. Kontroller UAT-sektionen i den skabelon.

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

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

= > Her er et brugeraccept testprøveeksempeldokument

brugeraccept test design design

De samlede 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.)

Testtabel for 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 bare en delmængde, da vi tester alle applikationerne i modsætning til kun de vigtigste funktionelle områder.

Ud over disse, dataene, skabeloner til registrering af testresultater, administrative procedurer, fejlloggingsmekanisme, osv. skal være på plads, inden vi går videre til næste fase.

Testudførelse

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

Eller hvis QA-teamet udfører testene, kører vi testen sager om AUT.

Når alle testene er kørt, og resultaterne er i hånden, træffes acceptbeslutningen. Dette kaldes også Go / No-Go-beslutningen. Hvis brugerne er tilfredse, er det en Go, ellers er det en No-go.

At nå beslutningen om accept er typisk slutningen af denne fase.

Værktøjer & Metoder

Typen af softwareværktøjer, der bruges i denne testfase, svarer typisk til de værktøjer, der anvendes under funktionel test.

Værktøjer:

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. Til en vis grad ville vi dog være i stand til at udnytte de automatiske scripts, der blev udviklet under systemtest.

I lighed med systemtest bruger brugerne også teststyring 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 for produktet, stadig er relevante, i en virkelig global i verden som i dag skal brugeracceptstest undertiden involvere forskellige kunder på tværs af lande baseret på produktet.

For eksempel ville et e-handelswebsted blive brugt af kunder over hele kloden. I scenarier som denne ville crowdtest være den bedste løsning.

Crowdtest 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 leverede tilbagemeldinger analyseres og prioriteres derefter.

Crowd Testing-metodologi 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 i stille krav og derved opdatere produktforsinkelsen. I slutningen af hver sprint ville forretningsbrugere deltage i sprintdemoen og 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 produktbackloggen, som konstant gennemgås og prioriteres. Således i en agil verden er forretningsbrugere tættere på projektet, og de vurderer det samme til dets brug oftere i modsætning til de traditionelle vandfaldsprojekter.

UAT Team – Roller & 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 af milliarder dollars eller et opstartteam, du skal overvinde alle disse udfordringer for at levere succesrig software til slutbrugeren.

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

Udførelse af denne test i det samme miljø, der bruges af det funktionelle testteam, vil helt sikkert ende med at overse de virkelige brugssager. Desuden kan vigtige testaktiviteter som præstationstest ikke udføres i et testmiljø med ufuldstændige testdata.

Et separat produktionslignende miljø skal oprettes 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) Test Planlæ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 vil spise UAT-tiden op.

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. Kernemålene for denne test kan ikke opnå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) Ufaglærte testere eller testere uden forretningskendskab:

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

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

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

# 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) Bed funktionelt testteam om at udføre denne test:

Der er ingen dårligere situation end at bede om funktionstesten team til at udføre UAT.

Kunder aflæsser deres ansvar over for testteamet på grund af manglende 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) The Blame Game

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 vs Test af brugeraccept

Testteamets involvering starter ganske tidligt i projekt lige fra kravanalysefasen.

Gennem hele projektets livscyklus udføres en form for validering for projektet, dvs. Statisk test, Enhedstest, Systemtest, integrationstest, en ende til slut-test 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 bevare uafhængigheden mellem begge faser, hvilket ville give hurtigere markedsføringstid.

Konklusion

# 1) UAT handler ikke om sider, felter eller knapper. Den 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. 🙁

# 2) 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, UAT handler ikke om at søge efter den menu, der åbner en side osv. Det handler om billetterne og deres reservation, de stater, den kan tage, sin rejse gennem systemet osv.

Et andet 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 er bedre til at gøre det end Virksomhedsejere. Derfor giver denne test mest mening, når kunden i høj grad er involveret.

# 3) UAT er også en form for test i kernen, hvilket betyder, at der er en god chance for identificere nogle bugs også i denne fase. Det sker undertiden. 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 som follo med denne test er der normalt ikke tid til at rette og teste igen.

Beslutningen er enten at:

• Skub go-live-datoen, rette problemet først og derefter gå videre.
• Lad bugten være som den er.
• Overvej det som en del af ændringsanmodningen om fremtidige udgivelser.

# 4) UAT er klassificeret som Alpha- og Beta-test, men denne klassificering er ikke så vigtig i sammenhæng 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 handel software.
• 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 almindeligt softwareudviklingsprojekt udføres UAT i QA-miljøet, hvis der er er ingen 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 faktisk at 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-selvstudieserie