Vad är användaracceptansprovning (UAT): En komplett guide

what is user acceptance testing

Lär dig vad som är UAT (User Acceptance Testing), tillsammans med dess definition, typer, steg och exempel:

Min regel nummer ett när jag försöker förstå ett nytt koncept är att: namnet kommer alltid att vara relevant och mestadels en bokstavlig betydelse (i det tekniska sammanhanget).

Att ta reda på vad det är kommer att ge en inledande förståelse för det och hjälpa mig att komma igång med.

hur man skriver automatiseringsprovskript

=> Klicka här för en fullständig handledningsserie för testplan

Låt oss testa detta koncept.

=> Läs alla handledning i vår Acceptance Testing-serie.

Vad du kommer att lära dig:

• Vad är testning av användaracceptans?
  • När utförs det?
  • Vem utför UAT?
  • Behov av testning av användaraccept
  • Testprocess för användaracceptans
  • UAT-styrning
  • UAT-testplanering
  • Design för användaracceptansprovning
  • Testutförande
  • Verktyg och metoder
  • UAT i smidig miljö
  • UAT Team - Roller och ansvar
• 7 utmaningar med UAT och mildringsplan
• Systemtestning mot testning av användaracceptans
• Slutsats
  • Rekommenderad läsning

Vad är testning av användaracceptans?

Vi vet vad testning är, acceptans betyder godkännande eller avtal. Användaren i samband med en programvaruprodukt är antingen konsumenten av programvaran eller den person som begärde att den skulle byggas åt honom / henne (klienten).

Så, efter min regel - kommer definitionen att vara:

User Acceptance Testing (UAT), även känt som beta- eller slutanvändartestning, definieras som att testa programvaran av användaren eller klienten för att avgöra om den kan accepteras eller inte. Detta är den slutliga testningen som utförs när funktionstestet, system- och regressionstestningen är klar.

Huvudsyftet med denna testning är att validera programvaran mot företagets krav. Denna validering utförs av slutanvändarna som är bekanta med företagskraven.

UAT, alfa- och betatestning är olika typer av acceptantestning.

Eftersom användaracceptansprovet är det sista testet som utförs innan programvaran sätts i drift är det uppenbarligen den sista chansen för kunden att testa programvaran och mäta om den är lämplig för ändamålet.

När utförs det?

Detta är vanligtvis det sista steget innan produkten sätts i drift eller innan leveransen av produkten accepteras. Detta utförs efter att själva produkten har testats noggrant (dvs. efter systemtestning ).

Vem utför UAT?

Användare eller klient - Detta kan antingen vara någon som köper en produkt (när det gäller kommersiell programvara) eller någon som har skräddarsytt en programvara genom en mjukvarutjänstleverantör eller slutanvändaren om programvaran görs tillgänglig för dem före tiden och när deras feedback efterfrågas.

Teamet kan bestå av betatestare eller kunden bör välja UAT-medlemmar internt från varje grupp i organisationen så att varje användarroll kan testas i enlighet med detta.

Behov av testning av användaraccept

Utvecklare och funktionstestare är tekniska personer som validerar programvaran mot funktionella specifikationer . De tolkar kraven enligt sin kunskap och utvecklar / testar programvaran (här är vikten av domenkunskap).

Denna programvara är komplett enligt funktionsspecifikationerna men det finns vissa affärskrav och processer som endast är kända för slutanvändarna missas antingen för att kommunicera eller misstolkas.

Denna testning spelar en viktig roll för att validera om alla affärsbehov uppfylls eller inte innan programvaran släpps för marknadsanvändning. Användningen av levande data och verkliga användningsfall gör denna testning till en viktig del av släppcykeln.

Många företag som lidit stora förluster på grund av problem efter lanseringen vet vikten av ett framgångsrikt test för användaracceptans. Kostnaden för att åtgärda defekterna efter släppningen är många gånger större än att åtgärda det tidigare.

Är UAT verkligen nödvändigt?

Efter att ha utfört massor av system, integration och regressionstest skulle man undra över nödvändigheten av denna testning. Egentligen är detta den viktigaste fasen i projektet eftersom det är den tid då användarna som faktiskt ska använda systemet skulle validera systemet för att passa det.

UAT är en testfas som till stor del beror på slutanvändarnas perspektiv och domänkunskapen hos en avdelning som representerar slutanvändarna.

I själva verket skulle det verkligen vara till hjälp för affärsteamen, om de var inblandade i projektet ganska tidigt, så att de kan ge sina åsikter och bidrag som skulle hjälpa till att använda systemet effektivt i den verkliga världen.

Testprocess för användaracceptans

Det enklaste sättet att förstå denna process är att tänka på detta som ett autonomt testprojekt - vilket innebär att det kommer att ha plan, design och exekveringsfaser.

Följande är förutsättningarna innan planeringsfasen börjar:

# 1) Samla de viktigaste acceptanskriterierna

Enkelt uttryckt är acceptanskriterierna en lista över saker som kommer att utvärderas innan de accepterar produkten.

Dessa kan vara av två typer:

(i) Applikationsfunktionalitet eller affärsrelaterad

Helst bör alla viktiga affärsfunktioner valideras, men på grund av olika skäl, inklusive tid, är det inte praktiskt att göra allt. Därför kan ett möte eller två med klienten eller användarna som kommer att vara involverade i denna testning ge oss en uppfattning om hur mycket testning som kommer att involveras och vilka aspekter som kommer att testas.

(ii) Avtalsenlig - Vi kommer inte att gå in på detta och QA-teamets medverkan i allt detta är nästan ingenting. Det ursprungliga kontraktet som upprättas redan innan SDLC börjar granskas och man når en överenskommelse om huruvida alla aspekter av kontraktet har levererats eller inte.

Vi kommer bara att fokusera på applikationsfunktionaliteten.

# 2) Definiera omfattningen av QA-engagemang.

QA-teamets roll är en av följande:

(i) Ingen delaktighet - Det här är väldigt sällsynt.

(ii) Hjälpa till vid denna testning - Mest vanliga. I det här fallet kan vårt engagemang vara att utbilda UAT-användare om hur man använder applikationen och vara i beredskap under denna testning för att se till att vi kan hjälpa användarna i händelse av problem. Eller i vissa fall kan vi, förutom att vara i beredskap och hjälpa, dela deras svar och registrera resultaten eller logga fel etc. medan användarna utför den faktiska testningen.

(iii) Utför UAT och presentera resultat - Om detta är fallet kommer användarna att peka på områdena för AUT som de vill utvärdera och själva utvärderingen utförs av QA-teamet. När det är gjort presenteras resultaten för klienterna / användarna och de kommer att fatta beslut om huruvida resultaten som de har i handen är tillräckliga eller inte och i enlighet med deras förväntningar för att acceptera AUT. Beslutet är aldrig QA-teamets.

Beroende på det aktuella fallet bestämmer vi vilken metod som är bäst.

De främsta målen och förväntningarna:

Vanligtvis utförs UAT av en ämne-expert (SME) och / eller en företagsanvändare, som kan vara ägare eller kund av ett testat system. I likhet med systemtestfasen omfattar UAT-fasen också religiösa faser innan den avslutas.

Nyckelaktiviteter för varje UAT-fas definieras nedan:

UAT-styrning

I likhet med systemtestning tillämpas effektiv styrning för UAT för att säkerställa att grindar av hög kvalitet tillsammans med de definierade inträdes- och utgångskriterierna (anges nedan **).

** Observera att det bara är en vägledning. Detta kan modifieras baserat på projektets behov och krav.

UAT-testplanering

Processen är nästan densamma som med regelbunden testplan i systemfasen.

Det vanligaste tillvägagångssättet i de flesta av projekten är att planera för både system- och UAT-testfaser tillsammans. Mer information om UAT-testplanen tillsammans med ett prov finns i bifogade testplandokumentets UAT-avsnitt.

Testplan för användaracceptans

(Detta är detsamma som du skulle hitta på vår webbplats för QA-träningsserien också).

Klicka på bilden nedan och bläddra ner för att hitta testplanens dokumentexempel i olika format. Kontrollera UAT-avsnittet i den mallen.

Datum, miljö, aktörer (vem), kommunikationsprotokoll, roller och ansvarsområden, mallar, resultat och deras analysprocess, inträde / utgångskriterier - allt detta och allt annat som är relevant finns i UAT-testplanen.

Oavsett om QA-teamet deltar, delvis deltar eller inte deltar alls i detta test, är det vårt jobb att planera denna fas och se till att allt tas med i beräkningen.

=> Här är ett testdokument för användaracceptans

Design för användaracceptansprovning

De samlade acceptanskriterierna från användarna används i detta steg. Prover kan se ut som visas nedan.

(Dessa är utdrag från CSTE CBOK . Detta är en av de bästa referenser som finns tillgängliga om denna testning.)

Testmall för användaracceptans:

Baserat på kriterierna ger vi (QA-teamet) användarna en lista över UAT-testfall. Dessa testfall skiljer sig inte från våra vanliga systemtestfall. De är bara en delmängd eftersom vi testar alla applikationer i motsats, bara till de viktigaste funktionella områdena.

Utöver dessa måste data, mallar för att registrera testresultat, administrativa procedurer, felloggningsmekanism etc. vara på plats innan vi går vidare till nästa fas.

Testutförande

Vanligtvis, när det är möjligt, sker denna testning i en konferens eller i ett krigsrum som en uppsättning där användarna, PM, QA-teamrepresentanterna alla sitter tillsammans en dag eller två och arbetar igenom alla fall av acceptansprov.

Eller om QA-teamet utför testerna kör vi testfallet på AUT.

När alla tester har körts och resultaten är i handen, Godkännandebeslut är gjord. Detta kallas också Go / No-Go-beslut . Om användarna är nöjda är det Go, annars är det No-go.

Att nå acceptansbeslutet är typiskt slutet på denna fas.

gratis webbaserad klockprogramvara

Verktyg och metoder

Typiskt liknar den typ av programvaruverktyg som används under denna testfas de verktyg som används vid funktionstestning.

Verktyg:

Eftersom denna fas involverar valideringen av hela slutet till slutet-flödet av applikationen kan det vara svårt att ha ett verktyg för att automatisera denna validering helt. I viss utsträckning skulle vi dock kunna utnyttja de automatiserade skript som utvecklats under systemtestning.

I likhet med systemtest skulle användare också använda testhanterings- och defekthanteringsverktyg som QC, JIRA, etc. Dessa verktyg kan konfigureras för att samla data för användaracceptfasen.

Metoder:

Även om konventionella metoder som specifika affärsanvändare som utför UAT av produkten fortfarande är relevanta, måste en användaracceptstest ibland involvera olika kunder i olika länder baserat på produkten i en verkligt global värld som idag.

Till exempel, en e-handelswebbplats skulle användas av kunder över hela världen. I sådana scenarier skulle publiktestning vara det bästa alternativet.

Publiktestning är en metod där människor från hela världen kan delta och validera användningen av produkten och ge förslag och rekommendationer.

Crowd-testplattformar är byggda och används av många organisationer nu. En webbplats eller en produkt som måste testas för publiken finns på plattformen och kunderna kan nominera sig själva för att göra valideringen. De återkopplingar som tillhandahålls analyseras och prioriteras sedan.

Crowd Testing-metodik visar sig vara effektivare eftersom kundens puls över hela världen lätt kan förstås.

UAT i smidig miljö

Den smidiga miljön är mer dynamisk till sin natur. I en smidig värld kommer företagsanvändare att vara involverade under hela projektsprinten och projektet skulle förbättras baserat på återkopplingsslingorna från dem.

I början av projektet skulle företagsanvändare vara de viktigaste intressenterna för att ställa krav och därigenom uppdatera produktbackloggen. Under slutet av varje sprint skulle företagsanvändare delta i sprintdemoen och skulle vara tillgängliga för att ge feedback.

Dessutom skulle en UAT-fas planeras före sprintens slutförande där affärsanvändarna skulle göra sina valideringar.

De återkopplingar som tas emot under sprintdemo och sprint UAT, samlas in och läggs tillbaka till produktbackloggen som kontinuerligt granskas och prioriteras. Således i en smidig värld är affärsanvändarna mer nära projektet och de utvärderar detsamma för dess användning oftare till skillnad från traditionella vattenfallsprojekt.

UAT Team - Roller och ansvar

En typisk UAT-organisation skulle ha följande roller och ansvar. UAT-teamet stöds av projektledaren, utvecklings- och testteam baserat på deras behov.

7 utmaningar med UAT och mildringsplan

Det spelar ingen roll om du är en del av en miljarddollar eller ett startteam, du bör övervinna alla dessa utmaningar för att leverera framgångsrik programvara för slutanvändaren.

# 1) Installations- och distributionsprocess för miljö:

Att genomföra detta test i samma miljö som används av det funktionella testteamet kommer säkert att hamna med utsikt över verkliga användningsfall. Dessutom kan viktiga testaktiviteter som prestandatest inte utföras i en testmiljö med ofullständig testdata .

En separat produktionsliknande miljö bör inrättas för detta test.

När UAT-miljön har separerats från testmiljön måste du kontrollera frigöringscykeln effektivt. Okontrollerad utgivningscykel kan leda till olika programvaruversioner i test- och UAT-miljö. Värdefull acceptans testtid slösas bort när programvaran inte testas i den senaste versionen.

Under tiden är tiden som krävs för att spåra problem på fel programversion hög.

# 2) Testplanering:

Denna testning bör planeras med en tydlig testplan för acceptans i kravanalys och designfas.

I strategiplanering bör uppsättningen av verkliga användningsfall identifieras för utförande. Det är mycket viktigt att definiera testmålen för denna testning eftersom ett fullständigt testkörning inte är möjligt för stora applikationer i denna testfas. Testning bör utföras genom att prioritera viktiga affärsmål först.

Denna testning utförs i slutet av testcykeln. Uppenbarligen är det den mest kritiska perioden för programversionen. Fördröjning i något av de tidigare stadierna av utveckling och testning kommer att äta upp UAT-tiden.

Felaktig testplanering leder i värsta fall till en överlappning mellan systemtestningen och UAT. På grund av mindre tid och tryck för att uppfylla deadlines distribueras programvaran till den här miljön även om funktionstestning inte är klar. Kärnmålen för denna testning kan inte uppnås i sådana situationer.

UAT-testplanen bör utarbetas och kommuniceras till teamet i god tid innan du börjar testet. Detta hjälper dem vid testplanering, skrivning av testfall och testskript och att skapa en UAT-miljö.

# 3) Hantering av nya affärsbehov som incidenter / defekter:

Oklarheter i kraven fastnar i UAT-fasen. UAT-testare hittar problem som uppstår på grund av tvetydiga krav (genom att titta på det fullständiga användargränssnittet som inte fanns tillgängligt under kravuppsamlingsfasen) och logga det som en defekt.

Kunden förväntar sig att dessa fixas i den aktuella versionen utan att ta hänsyn till tiden för ändringsförfrågningarna. Om projektledningen inte fattar ett snabbt beslut om dessa sista minuten-ändringar kan detta leda till att misslyckandet släpps.

# 4) Okvalificerade testare eller testare utan företagskunskap:

När det inte finns något permanent team väljer företaget UAT-personal från olika interna avdelningar.

Även om personalen är väl förtrogen med affärsbehovet, eller om de inte är utbildade för de nya kraven som utvecklas, kan de inte utföra effektiv UAT. Dessutom kan ett icke-tekniskt affärsgrupp möta många tekniska svårigheter att genomföra testfallet.

Under tiden tilldelar testare i slutet av UAT-cykeln inget värde till projektet. Liten tid att utbilda UAT-personalen kan avsevärt öka risken för UAT-framgång.

# 5) Felaktig kommunikationskanal:

Kommunikationen mellan fjärrutveckling, testning och UAT-teamet är svårare. E-postkommunikation är ofta mycket svårt när du har ett offshore-teknikteam. En liten tvetydighet i incidentrapporter kan fördröja korrigeringen för en dag.

Korrekt planering och effektiv kommunikation är avgörande för effektivt lagsamarbete. Projektgrupper bör använda ett webbaserat verktyg för att logga defekter och frågor. Detta hjälper till att fördela arbetsbelastningen jämnt och undvika rapportering av dubbletter.

# 6) Be funktionellt testteam att utföra denna testning:

Det finns ingen värre situation än att be det funktionella testteamet att utföra UAT.

Kunder överlämnar sitt ansvar till testteamet på grund av brist på resurser. Hela syftet med denna testning komprometteras i sådana fall. När programvaran har startats kommer slutanvändarna snabbt att upptäcka de frågor som inte betraktas som verkliga scenarier av funktionstestarna.

En lösning på detta är att tilldela denna testning till dedikerade och skickliga testare som har affärskunskap.

# 7) The Blame Game

Ibland försöker företagsanvändare bara hitta skäl att avvisa programvaran. Det kan vara deras självdom att visa hur överlägsen de är eller skylla utvecklings- och testteamet för att få respekt i affärsteamet. Detta är mycket sällsynt men händer i lag med intern politik.

Det är väldigt svårt att hantera sådana situationer. Att bygga ett positivt förhållande med affärsteamet skulle dock definitivt hjälpa till att undvika skulden.

Jag hoppas att dessa riktlinjer verkligen kommer att hjälpa dig att genomföra en framgångsrik användaracceptplan genom att lösa olika utmaningar. Korrekt planering, kommunikation, utförande och motiverat team är nycklarna till framgångsrik testning av användaraccept.

Systemtestning mot testning av användaracceptans

Testgruppens engagemang börjar ganska tidigt i projektet redan från kravanalysfasen.

Under hela projektets livscykel utförs någon form av validering för projektet, dvs. Statisk testning , Enhetstestning, Systemtestning, integrationstestning, testning från slut till slut eller regressionstest. Detta låter oss förstå bättre om testningen som utförts i UAT-fasen och hur annorlunda den är än den andra testningen som utförts tidigare.

Även om vi ser skillnaderna i SIT och UAT är det viktigt att vi utnyttjar synergier men ändå upprätthåller oberoendet mellan båda faserna, vilket möjliggör snabbare marknadsföringstid.

Slutsats

# 1) UAT handlar inte om sidor, fält eller knappar. Den underliggande antagande redan innan detta test börjar är att alla de grundläggande grejerna testas och fungerar bra. Gud förbjuder, användarna hittar ett fel så grundläggande som det - det är en bit av mycket dåliga nyheter för QA-teamet. :(

#två) Denna testning handlar om den enhet som är det primära elementet i verksamheten.

vilket program öppnar en json-fil

Låt mig ge dig ett exempel: Om AUT är ett biljettsystem kommer UAT inte att handla om, söker efter menyn som öppnar en sida etc. Det handlar om biljetterna och deras bokning, de stater som den kan ta, sin resa genom systemet, etc.

Annan Exempel, om sajten är en bilhandlare, så är fokus på 'bilen och dess försäljning' och egentligen inte webbplatsen. Därför är kärnverksamheten det som verifieras och valideras och vem som är bättre att göra det än företagsägarna. Det är därför som denna testning är mest meningsfullt när kunden är involverad i stor utsträckning.

# 3) UAT är också en form av test i sin kärna vilket betyder att det finns en god chans att identifiera några buggar också i denna fas . Ibland händer det. Bortsett från det faktum att det är en stor eskalering i QA-teamet betyder UAT-buggarna vanligtvis ett möte för att sitta och diskutera hur man hanterar dem eftersom det efter denna testning vanligtvis inte finns tid att fixa och testa om.

Beslutet skulle antingen att:

• Tryck på go-live-datumet, fixa problemet först och fortsätt sedan.
• Lämna felet som det är.
• Betrakta det som en del av ändringsbegäran för framtida släpp.

# 4) UAT klassificeras som alfa- och betatestning, men den klassificeringen är inte så viktig i samband med typiska programvaruutvecklingsprojekt i en tjänstebaserad industri.

• Alfatestning är när UAT utförs i mjukvarubyggarens miljö och är mer betydelsefullt i samband med kommersiell mjukvara.
• Betatestning är när UAT utförs i produktionsmiljön eller kundens miljö. Detta är vanligare för kundinriktade applikationer. Användarna här är de faktiska kunderna som du och jag i detta sammanhang.

# 5) För det mesta i ett regelbundet programvaruutvecklingsprojekt utförs UAT i QA-miljö om det inte finns någon iscensättning eller UAT-miljö.

Kortfattat, det bästa sättet att ta reda på om din produkt är acceptabel och lämplig för ändamålet är att faktiskt lägga den framför användarna.

Organisationer går in på det smidiga sättet att leverera, affärsanvändare blir mer engagerade och projekten förbättras och levereras via feedback-loopar. Allt som görs betraktas användaracceptationsfasen som grinden för att komma in i implementering och produktion.

Vad var din UAT-upplevelse? Var du i beredskap eller testade du för dina användare? Hittade användarna några problem? Om ja, hur hanterade du dem?

=> Läs också ALLA handledningar i denna serie här

=> Besök här för en komplett testplan-handledningsserie

Rekommenderad läsning

• Alpha Testing och Beta Testing (En komplett guide)
• Vad är acceptantestning (En komplett guide)
• Byggverifieringstestning (BVT-testning) Komplett guide
• Funktionell testning mot icke-funktionell testning
• Bästa verktyg för testning av programvara 2021 (QA Test Automation Tools)
• Typer av programvarutestning: Olika testtyper med detaljer
• ETL Testing Data Warehouse Testing Tutorial (En komplett guide)
• GUI Testing Tutorial: A Complete User Interface (UI) Testing Guide