Vad är användaracceptans testning (UAT): En komplett guide

Lär dig vad som är användaracceptans testning (UAT) , 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 teknisk kontext).

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

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

Låt oss testa detta koncept.

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

Vad är User Acceptance Testing?

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

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

Testning av användaracceptans (UAT), även känd som beta- eller slutanvändartestning, definieras som testning av 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 godkännandestester.

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

När utförs den?

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 grundligt (dvs. efter systemtestning).

Vem utför UAT?

Användare eller klient – Det kan vara någon som köper en produkt ( när det gäller kommersiell programvara) eller någon som har skräddarsytt en mjukvara genom en mjukvarutjänstleverantör eller slutanvändaren om programvaran görs tillgänglig för dem i förväg och när deras feedback söks.

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 därmed.

Behov för testning av användaracceptans

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

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

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 utgivningscykeln.

Många företag som lidit stora förluster på grund av problem efter utgivningen vet vikten av ett framgångsrikt användaracceptansprov. Kostnaden för att åtgärda defekterna efter utgivningen ä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-, integrations- 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 ett test fas som till stor del beror på slutanvändarnas perspektiv och domänkunskapen hos en avdelning som representerar slutanvändarna.

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

Testningsprocess för användaracceptans

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 före planeringsfasen. börjar:

# 1) Samla de viktigaste acceptanskriterierna

Enkelt uttryckt är acceptanskriterierna en lista över dessa företag som ska 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 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) Kontrakt – 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 en överenskommelse nås om 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 – Detta är väldigt sällsynt.

(ii) Hjälper till vid denna testning – Mest allmänning. 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 spela in resultaten eller logga fel etc. medan användarna utför den faktiska testningen.

(iii) Utför UAT och nuvarande resultat – Om så ä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 fattas aldrig av QA-teamet.

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

De primära målen och förväntningarna:

Vanligtvis utförs UAT av en ämnesämnesexpert (SME) och / eller en företagsanvändare, som kan vara ägare eller kund till 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 är bara en vägledning. Detta kan modifieras baserat på projektbehov och krav.

UAT-testplanering

Processen är nästan densamma som med den vanliga testplanen 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. För mer information om UAT-testplanen tillsammans med ett exempel, vänligen kolla in bifogade testplan-dokumentets UAT-avsnitt.

Testplan för användaracceptans

(Detta är detsamma som du skulle ha 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, kriterier för inträde / utgång – allt detta och allt annat som är relevant finns i UAT-testplanen.

Oavsett om QA-teamet deltar, delvis deltar eller inte alls deltar 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 användardokument Testplan Exempeldokument

Användaracceptans testdesign

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. Det här är en av de bästa referenserna som finns tillgängliga om denna testning.)

Testmall för användaraccept:

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, data, mallar för att registrera testresultat, administrativa procedurer, defektloggningsmekanism, etc. måste 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 ställa in där användare, PM, QA-teamrepresentanter alla sitter tillsammans en dag eller två och arbetar igenom alla godkännande testfall.

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

När alla tester har körts och resultaten är i hand fattas beslutet om godkännande. Detta kallas också Go / No-Go-beslutet. Om användarna är nöjda är det Go, annars är det No-go.

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

Verktyg & Metoder

Typen av programvaruverktyg som används under denna testfas liknar de verktyg som används vid funktionstestning.

Verktyg:

Eftersom denna fas involverar validering av applikationens fullständiga flöden från slut till slut kan det vara svårt att ha ett verktyg för att automatisera denna validering. I viss utsträckning skulle vi dock kunna utnyttja de automatiska skript som utvecklats under systemtestning.

Liksom systemtestning skulle användarna också använda testhantering och defekthanteringsverktyg som QC, JIRA, etc. Dessa Verktyg kan konfigureras för att kumulera data för användaracceptansfasen.

Metoder:

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

Till exempel skulle en e-handelswebbplats användas av kunder över hela världen. I scenarier som detta skulle folkmassatestning vara det bästa alternativet.

Crowdtestning ä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 mer effektiv eftersom kundens puls över hela världen lätt kan förstås.

UAT In Agile Environment

Den smidiga miljön är mer dynamisk. 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 tillhandahålla krav och därigenom uppdatera produktstocken. Under slutet av varje sprint skulle företagsanvändare delta i sprintdemo och skulle vara tillgängliga för att ge feedback.

Dessutom skulle en UAT-fas planeras innan sprintfärdigställandet där affärsanvändarna skulle göra sitt valideringar.

Återkopplingarna som tas emot under sprintdemo och sprint UAT, samlas 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 & 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 för UAT Och Mitigation Plan

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

# 1) Miljöinstallations- och utplaceringsprocess:

Att genomföra detta test i samma miljö som det funktionella testteamet använder kommer definitivt att se ut över de verkliga användningsfallen. Avgörande testaktiviteter som prestandatest kan inte utföras i en testmiljö med ofullständig testdata.

En separat produktionsliknande miljö bör ställas in 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 tid slösas bort när programvaran inte testas i den senaste versionen.

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

# 2) Test Planering:

Denna testning bör planeras med en tydlig acceptansplan 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 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 meddelas teamet långt innan du börjar testet. Detta hjälper dem att testplanera, skriva testfall & testskript och skapa en UAT-miljö.

# 3) Hantera 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 beslut i rätt tid om dessa sista minuten-ändringar kan detta leda till att misslyckandet släpps.

# 4) Okvalificerade testare eller testare utan affärskunskap:

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 är utvecklas kan de inte utföra effektiv UAT. Dessutom kan ett icke-tekniskt affärsteam möta många tekniska svårigheter när det gäller att utföra testfallet.

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

# 5) Felaktig kommunikationskanal:

Kommunikation mellan fjärrutveckling, testning och UAT-team är svårare . E-postkommunikation är ofta mycket svårt när du har ett offshore-teknikteam. En liten tvetydighet i incidentrapporter kan försena åtgärden för en dag.

Korrekt planering och effektiv kommunikation är avgörande för effektivt teamsamarbete. 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 funktionstestteamet att utföra denna testning:

Det finns ingen sämre situation än att be funktionstestet team för 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 problem som inte betraktas som verkliga scenarier av funktionstestarna.

En lösning på detta är att tilldela denna testning till de 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 team 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 skuldspelet.

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, körning och motiverat team är nycklarna till framgångsrik testning av användaracceptans.

Systemtestning vs Testning av användaracceptans

Testteamets engagemang börjar ganska tidigt under projekt direkt 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 behåll fortfarande oberoendet mellan båda faserna vilket möjliggör snabbare marknadsföringstid.

Slutsats

# 1) UAT handlar inte om sidor, fält eller knappar. Det underliggande antagandet redan innan detta test börjar är att allt det 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. 🙁

# 2) Denna testning handlar om den enhet som är den primära delen i verksamheten.

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

Ett annat exempel, om webbplatsen är en bilförsäljningsplats, så är fokus på ”bilen och dess försäljning” och inte riktigt webbplatsen. Därför är kärnverksamheten det som verifieras och valideras och vem är bättre att göra det än företagare. 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 innebär att det finns goda chanser att identifiera några buggar i denna fas också. Det händer ibland. Bortsett från 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 som följer med denna testning finns det vanligtvis ingen tid att fixa och testa om igen.

Beslutet skulle antingen vara att:

• Tryck på go-live-datumet, fixa problemet först och sedan gå vidare.
• Lämna felet som det är.
• Betrakta det som en del av ändringsbegäran för framtida utgåvor.

# 4) UAT klassificeras som alfa- och betatestning, men den klassificeringen är inte så viktig inom ramen för typiska mjukvaruutvecklingsprojekt i en servicebaserad industri.

• Alfatestning är när UAT utförs i mjukvarubyggarens miljö och är mer betydelsefullt i samband med kommersiell hylla programvara.
• Betatestning är när UAT utförs i produktionsmiljön eller klientens 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 finns är ingen iscensättning eller UAT-miljö.

Kort sagt, 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. När allt är klart 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 även ALLA självstudier i denna serie här

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