Hva er brukertest (UAT): En komplett guide

what is user acceptance testing

Lær hva som er brukerattest (UAT), sammen med definisjon, typer, trinn og eksempler:

Min regel nummer én når jeg prøver å forstå et nytt konsept er at: navnet kommer alltid til å være relevant og stort sett en bokstavelig betydning (i teknisk sammenheng).

Å finne ut hva det er, vil gi en innledende forståelse av det og hjelpe meg å komme i gang med.

manuelle tester intervju spørsmål for 3 års erfaring

=> Klikk her for fullstendig testplanopplæringsserie

La oss sette dette konseptet på prøve.

=> Les alle veiledningene i vår Acceptance Testing-serie.

Hva du vil lære:

• Hva er testing av brukertillatelse?
  • Når utføres det?
  • Hvem utfører UAT?
  • Behov for testing av brukeraksept
  • Testprosess for brukeraksept
  • UAT Governance
  • UAT Testplanlegging
  • Design for brukertest
  • Testutførelse
  • Verktøy og metoder
  • UAT i smidig miljø
  • UAT Team - Roller og ansvar
• 7 utfordringer med UAT og avbøtningsplan
• Systemtesting mot brukertestetesting
• Konklusjon
  • Anbefalt lesing

Hva er testing av brukertillatelse?

Vi vet hva testing er, aksept betyr godkjenning eller avtale. Brukeren i sammenheng med et programvareprodukt er enten forbrukeren av programvaren eller den personen som ba om at den skulle bygges for ham / henne (klient).

Så etter min regel - vil definisjonen være:

User Acceptance Testing (UAT), også kjent som beta- eller sluttbrukertesting, er definert som testing av programvaren av brukeren eller klienten for å avgjøre om den kan aksepteres eller ikke. Dette er den endelige testingen som utføres når funksjonalitet, system- og regresjonstesting er fullført.

Hovedformålet med denne testingen er å validere programvaren mot forretningskravene. Denne valideringen utføres av sluttbrukerne som er kjent med forretningskravene.

UAT, alfa- og betatesting er forskjellige typer akseptantesting.

Ettersom brukeracceptansetesten er den siste testen som er utført før programvaren setter i gang, er det åpenbart den siste sjansen for kunden å teste programvaren og måle om den er egnet til formålet.

Når utføres det?

Dette er vanligvis det siste trinnet før produktet tas i bruk eller før levering av produktet blir akseptert. Dette utføres etter at selve produktet er grundig testet (dvs. etter systemtesting ).

Hvem utfører UAT?

Brukere eller klienter - Dette kan enten være noen som kjøper et produkt (i tilfelle kommersiell programvare) eller noen som har fått en programvare spesialtilpasset gjennom en programvaretjenesteleverandør eller sluttbrukeren hvis programvaren blir gjort tilgjengelig for dem før tiden og når deres tilbakemeldinger blir oppsøkt.

Teamet kan bestå av betatestere eller kunden bør velge UAT-medlemmer internt fra hver gruppe i organisasjonen, slik at hver brukerrolle kan testes tilsvarende.

Behov for testing av brukeraksept

Utviklere og funksjonstestere er tekniske personer som validerer programvaren mot funksjonelle spesifikasjoner . De tolker kravene i henhold til sin kunnskap og utvikler / tester programvaren (her er viktigheten av domenekunnskap).

Denne programvaren er komplett i henhold til funksjonelle spesifikasjoner, men det er noen forretningskrav og prosesser som bare er kjent for sluttbrukerne, er enten savnet å kommunisere eller feiltolkes.

Denne testingen spiller en viktig rolle for å validere om alle forretningskravene er oppfylt eller ikke før programvaren slippes for markedsbruk. Bruk av live data og reelle brukssaker gjør denne testen til en viktig del av utgivelsessyklusen.

Mange virksomheter som har hatt store tap på grunn av problemer etter utgivelsen, vet viktigheten av en vellykket brukeracceptansetest. Kostnaden for å fikse feilene etter løslatelse er mange ganger større enn å fikse den tidligere.

Er UAT virkelig nødvendig?

Etter å ha utført massevis av system-, integrasjons- og regresjonstesting, ville man lure på nødvendigheten av denne testingen. Egentlig er dette den viktigste fasen i prosjektet, da dette er tidspunktet da brukerne som faktisk skal bruke systemet, vil validere systemet for å passe til formålet.

UAT er en testfase som i stor grad avhenger av sluttbrukernes perspektiv og domenekunnskapen til en avdeling som representerer sluttbrukerne.

Faktisk vil det virkelig være nyttig for forretningsteamene hvis de var involvert i prosjektet ganske tidlig, slik at de kan gi sine synspunkter og bidrag som vil hjelpe effektiv bruk av systemet i den virkelige verden.

Testprosess for brukeraksept

Den enkleste måten å forstå denne prosessen er å tenke på dette som et autonomt testprosjekt - som betyr at det vil ha plan, design og utførelsesfaser.

Følgende er forutsetningene før planleggingsfasen begynner:

# 1) Samle de viktigste akseptkriteriene

Enkelt sagt er akseptkriterier en liste over ting som skal evalueres før de godtar produktet.

Disse kan være av to typer:

(i) Søknadsfunksjonalitet eller forretningsrelatert

Ideelt sett bør alle viktige forretningsfunksjonaliteter bli validert, men på grunn av forskjellige årsaker, inkludert tid, er det ikke praktisk å gjøre alt. Derfor kan et møte eller to med klienten eller brukerne som skal være involvert i denne testingen gi oss en ide om hvor mye testing som skal involveres og hvilke aspekter som skal testes.

(ii) Kontraktuell - Vi kommer ikke til å gå inn på dette og involveringen av QA-teamet i alt dette er nesten ingenting. Den første kontrakten som blir utarbeidet allerede før SDLC begynner blir gjennomgått og det blir enighet om alle aspektene ved kontrakten er levert eller ikke.

Vi skal bare fokusere på applikasjonsfunksjonaliteten.

# 2) Definer omfanget av QA-involvering.

QA-teamets rolle er en av følgende:

(i) Ingen involvering - Dette er veldig sjeldent.

(ii) Hjelp i denne testen - Mest vanlig. I dette tilfellet kan vårt engasjement være å trene UAT-brukerne om hvordan du bruker applikasjonen og være i beredskap under denne testingen for å sikre at vi kan hjelpe brukerne i tilfelle problemer. I noen tilfeller kan vi, i tillegg til å være i beredskap og hjelpe, dele svarene deres og registrere resultatene eller logge feil osv. Mens brukerne utfører den faktiske testen.

(iii) Utfør UAT og presenter resultater - Hvis dette er tilfelle, vil brukerne peke på områdene til AUT som de vil evaluere, og selve evalueringen utføres av QA-teamet. Når dette er gjort, blir resultatene presentert for klientene / brukerne, og de vil ta en avgjørelse om resultatene de har i hånden er tilstrekkelige eller ikke, og i samsvar med deres forventninger for å akseptere AUT. Avgjørelsen er aldri den for QA-teamet.

Avhengig av saken som er til stede, bestemmer vi hvilken tilnærming som er best.

De primære målene og forventningene:

Vanligvis utføres UAT av en emneekspert (SME) og / eller en bedriftsbruker, som kan være eier eller kunde av et system som testes. I likhet med systemtestfasen omfatter UAT-fasen også religiøse faser før den avsluttes.

Nøkkelaktiviteter i hver UAT-fase er definert nedenfor:

UAT Governance

I likhet med systemtesting håndheves effektiv styring for UAT for å sikre at kvalitetsporter sammen med de definerte inngangs- og utgangskriteriene (gitt nedenfor **).

** Vær oppmerksom på at det bare er en veiledning. Dette kan endres ut fra prosjektets behov og krav.

UAT Testplanlegging

Prosessen er nesten den samme som med vanlig testplan i systemfasen.

Den vanligste tilnærmingen som følges i de fleste prosjektene er å planlegge for både system- og UAT-testfaser sammen. For mer informasjon om UAT-testplanen sammen med et utvalg, kan du sjekke ut vedlagte testplandokumentets UAT-seksjoner.

Testplan for brukeraksept

(Dette er det samme som du vil finne på vår side for QA-treningsserien også).

Klikk på bildet nedenfor, og bla ned for å finne testplanens dokumenteksempel i forskjellige formater. I Undersøk malen.

Datoer, miljø, aktører (hvem), kommunikasjonsprotokoller, roller og ansvar, maler, resultater og deres analyseprosess, inngangs- og utgangskriterier - alt dette og alt annet som er relevant, vil bli funnet i UAT-testplanen.

Enten QA-teamet deltar, delvis deltar eller ikke deltar i det hele tatt i denne testen, er det vår jobb å planlegge denne fasen og sørge for at alt blir tatt i betraktning.

=> Her er et testdokument for brukeracceptans

Design for brukertest

De samlede akseptkriteriene fra brukerne blir brukt i dette trinnet. Prøver kan se ut som vist nedenfor.

(Dette er utdrag fra CSTE CBOK . Dette er en av de beste referansene som er tilgjengelige om denne testen.)

Mal for testing av brukertillatelse:

Basert på kriteriene gir vi (QA-teamet) brukerne en liste over UAT-testtilfeller. Disse testtilfellene er ikke forskjellige fra våre vanlige systemtesttilfeller. De er bare et delsett når vi tester alle applikasjonene i motsetning, bare til de viktigste funksjonelle områdene.

I tillegg til disse, må data, maler for å registrere testresultater, administrative prosedyrer, feilloggingsmekanisme osv. Være på plass før vi går videre til neste fase.

Testutførelse

Vanligvis, når det er mulig, skjer denne testen i en konferanse eller i et krigsrom, et slags oppsett der brukerne, PM, QA-teamrepresentanter alle sitter sammen en dag eller to og jobber gjennom alle aksepttestesakene.

prøve testplan for programvaretesting

Eller i tilfelle QA-teamet utfører testene, kjører vi testsakene på AUT.

Når alle testene er kjørt og resultatene er i hånden, vil Akseptbeslutning er laget. Dette kalles også Go / No-Go-avgjørelse . Hvis brukerne er fornøyde, er det Go, ellers er det No-go.

Å nå akseptavgjørelsen er vanligvis slutten på denne fasen.

Verktøy og metoder

Typisk er typen programvareverktøy som brukes i løpet av denne testfasen lik verktøyene som brukes mens funksjonstesting utføres.

Verktøy:

Siden denne fasen innebærer validering av hele strømmen til applikasjonen, kan det være vanskelig å ha ett verktøy for å automatisere denne valideringen. Imidlertid vil vi til en viss grad kunne utnytte de automatiserte skriptene som ble utviklet under systemtesting.

I likhet med systemtesting, vil brukerne også bruke testadministrasjons- og feilhåndteringsverktøy som QC, JIRA, etc. Disse verktøyene kan konfigureres til å kumulere data for brukerakseptfasen.

Metoder:

Selv om konvensjonelle metoder som spesifikke forretningsbrukere som utfører UAT av produktet, fremdeles er relevante, i en virkelig global verden som i dag, må brukertilsynstesting noen ganger involvere varierte kunder på tvers av land basert på produktet.

For eksempel, et netthandelsnettsted vil bli brukt av kunder over hele verden. I scenarier som dette vil mengdetesting være det beste levedyktige alternativet.

Publikumstesting er en metodikk der mennesker fra hele verden kan delta og validere bruken av produktet og komme med forslag og anbefalinger.

Publikumstesteplattformer er bygget og blir brukt av mange organisasjoner nå. Et nettsted eller et produkt som må testes med mengder, er vert for plattformen, og kundene kan nominere seg selv til å gjøre valideringen. Tilbakemeldingene som gis blir deretter analysert og prioritert.

Crowd Testing-metodikk viser seg å være mer effektiv ettersom pulsen til kunden over hele verden lett kan forstås.

UAT i smidig miljø

Det smidige miljøet er mer dynamisk. I en smidig verden vil forretningsbrukere være involvert i hele prosjektsprinten, og prosjektet vil bli forbedret basert på tilbakemeldingsløkkene fra dem.

I begynnelsen av prosjektet ville forretningsbrukere være de viktigste interessentene for å stille krav og derved oppdatere produktetterslepet. Under slutten av hver sprint ville forretningsbrukere delta i sprintdemoen og være tilgjengelig for tilbakemelding.

Videre vil en UAT-fase planlegges før sprintavslutningen der bedriftsbrukerne gjør valideringene sine.

Tilbakemeldingene som mottas under sprintdemo og sprint UAT, samles og legges tilbake til produktetterslepet som hele tiden blir gjennomgått og prioritert. Således i en smidig verden er forretningsbrukerne nærmere prosjektet, og de vurderer det samme for bruk oftere i motsetning til tradisjonelle fosseprosjekter.

UAT Team - Roller og ansvar

En typisk UAT-organisasjon vil ha følgende roller og ansvar. UAT-teamet vil bli støttet av prosjektleder, utviklings- og testteam basert på deres behov.

7 utfordringer med UAT og avbøtningsplan

Det spiller ingen rolle om du er en del av en milliard dollar-utgivelse eller et oppstartslag, du bør overvinne alle disse utfordringene for å levere vellykket programvare til sluttbrukeren.

# 1) Miljøoppsett og distribusjonsprosess:

Å utføre denne testen i samme miljø som det funksjonelle testteamet bruker, vil helt sikkert havne med utsikt over de virkelige brukssakene. Også avgjørende testaktiviteter som ytelsestesting kan ikke utføres i et testmiljø med ufullstendig testdata .

Det bør settes opp et eget produksjonslignende miljø for denne testen.

Når UAT-miljøet er skilt fra testmiljøet, må du kontrollere utgivelsessyklusen effektivt. Ukontrollert utgivelsessyklus kan føre til forskjellige programvareversjoner på test- og UAT-miljø. Verdifull godkjenningstest er bortkastet når programvaren ikke testes på den nyeste versjonen.

I mellomtiden er tiden som kreves for å spore problemer på feil programvareversjon, høy.

# 2) Testplanlegging:

Denne testingen bør planlegges med en klar akseptplan for planlegging i kravanalysen og designfasen.

I strategiplanlegging bør settet med virkelige brukssaker identifiseres for utførelse. Det er veldig viktig å definere testmålene for denne testingen, da en fullstendig testutførelse ikke er mulig for store applikasjoner i denne testfasen. Testing bør utføres ved å prioritere kritiske forretningsmål først.

Denne testen utføres på slutten av testsyklusen. Åpenbart er det den mest kritiske perioden for programvareutgivelsen. Forsinkelse i noen av de forrige stadiene av utvikling og testing vil spise opp UAT-tiden.

Feil testplanlegging fører i verste tilfeller til en overlapping mellom systemtesting og UAT. På grunn av mindre tid og press for å overholde frister, blir programvaren distribuert til dette miljøet, selv om funksjonstesting ikke er fullført. Kjernemålene for denne testingen kan ikke oppnås i slike situasjoner.

UAT-testplanen bør utarbeides og formidles til teamet i god tid før du begynner på denne testen. Dette vil hjelpe dem med testplanlegging, skriving av testtilfeller og testskript og oppretting av et UAT-miljø.

# 3) Håndtering av nye forretningskrav som hendelser / mangler:

Uklarheter i kravene blir fanget i UAT-fasen. UAT-testere finner problemer som oppstår på grunn av tvetydige krav (ved å se på det komplette brukergrensesnittet som ikke var tilgjengelig under kravinnsamlingsfasen) og logge det som en feil.

Kunden forventer at disse blir løst i den nåværende utgivelsen uten å vurdere tidspunktet for endringsforespørslene. Hvis prosjektledelsen ikke tar en rettidig avgjørelse om disse endringene i siste øyeblikk, kan dette føre til utgivelsesfeilen.

# 4) Ufaglærte testere eller testere uten forretningskunnskap:

Når det ikke er noe fast team, velger selskapet UAT-ansatte fra forskjellige interne avdelinger.

Selv om personalet er godt kjent med forretningsbehovet, eller hvis de ikke er opplært for de nye kravene som utvikles, kan de ikke utføre effektiv UAT. Et ikke-teknisk forretningsteam kan også møte mange tekniske problemer med å utføre testsakene.

I mellomtiden gir ikke testere på slutten av UAT-syklusen prosjektet noen verdi. Lite tid til å trene UAT-ansatte kan øke sjansene for UAT-suksess betydelig.

# 5) Feil kommunikasjonskanal:

Kommunikasjon mellom fjernutvikling, testing og UAT-teamet er vanskeligere. E-postkommunikasjon er ofte veldig vanskelig når du har et offshore tech-team. En liten tvetydighet i hendelsesrapporter kan forsinke løsningen for en dag.

Riktig planlegging og effektiv kommunikasjon er avgjørende for effektivt teamsamarbeid. Prosjektgrupper bør bruke et nettbasert verktøy for å logge feil og spørsmål. Dette vil bidra til å fordele arbeidsmengden jevnt og unngå å rapportere duplikatproblemer.

# 6) Be funksjonelt testteam om å utføre denne testen:

Det er ingen verre situasjon enn å be det funksjonelle testteamet om å utføre UAT.

Kunder avlaster sitt ansvar overfor testteamet på grunn av mangel på ressurser. Hele formålet med denne testingen blir kompromittert i slike tilfeller. Når programvaren er i bruk, vil sluttbrukerne raskt oppdage problemene som ikke blir betraktet som virkelige scenarier av funksjonstesterne.

En løsning på dette er å tildele denne testingen til dedikerte og dyktige testere som har forretningskunnskap.

# 7) The Blame Game

Noen ganger prøver forretningsbrukere bare å finne grunner til å avvise programvaren. Det kan være deres egendom å vise hvor overlegne de er eller klandre utviklings- og testteamet for å få respekt i forretningsteamet. Dette er veldig sjelden, men skjer i team med intern politikk.

Det er veldig vanskelig å takle slike situasjoner. Å bygge et positivt forhold til forretningsteamet vil imidlertid definitivt bidra til å unngå skyldspillet.

Jeg håper disse retningslinjene absolutt vil hjelpe deg med å gjennomføre en vellykket brukerakseptplan ved å overvinne forskjellige utfordringer. Riktig planlegging, kommunikasjon, gjennomføring og motivert team er nøklene til vellykket testing av brukeraksept.

hvordan åpne en XML-fil i Word

Systemtesting mot brukertestetesting

Involveringen av testteamet starter ganske tidlig i prosjektet helt fra kravanalysefasen.

Gjennom hele prosjektets livssyklus utføres en slags validering for prosjektet, dvs. Statisk testing , Enhetstesting, Systemtesting, integrasjonstesting, en ende-til-slutt-testing eller regresjonstesting. Dette lar oss forstå bedre om testingen som ble utført i UAT-fasen, og hvor forskjellig den er fra de andre testene som ble utført tidligere.

Selv om vi ser forskjellene i SIT og UAT, er det viktig at vi utnytter synergier, men likevel opprettholder uavhengigheten mellom begge fasene, noe som vil gi raskere markedsføringstid.

Konklusjon

#1) UAT handler ikke om sider, felt eller knapper. Det underliggende antagelse selv før denne testen begynner er at alt det grunnleggende er testet og fungerer bra. Gud forby brukerne finner en feil så grunnleggende som den - det er en veldig dårlig nyhet for QA-teamet. :(

#to) Denne testingen handler om enheten som er hovedelementet i virksomheten.

La meg gi deg et eksempel: Hvis AUT er et billettsystem, vil ikke UAT handle om, søke etter menyen som åpner en side, osv. Det handler om billettene og deres reservasjoner, statene det kan ta, sin reise gjennom systemet, etc.

En annen Eksempel, hvis nettstedet er et bilforhandlersted, så er fokuset på “bilen og dens salg” og egentlig ikke nettstedet. Derfor er kjernevirksomheten det som er verifisert og validert, og hvem er bedre å gjøre det enn bedriftseiere. Derfor gir denne testingen mest mening når kunden i stor grad er involvert.

# 3) UAT er også en form for testing i sin kjerne, noe som betyr at det er en god sjanse for å identifisere noen feil også i denne fasen . Noen ganger skjer det. Bortsett fra at det er en stor opptrapping på QA-teamet, betyr UAT-feil vanligvis et møte for å sitte og diskutere hvordan de skal håndteres, ettersom det etter denne testingen vanligvis ikke er tid til å fikse og teste på nytt.

Beslutningen vil enten være å:

• Trykk på go-live-datoen, fikse problemet først, og fortsett deretter.
• La feilen være som den er.
• Betrakt det som en del av endringsforespørselen for fremtidige utgivelser.

# 4) UAT er klassifisert som Alpha- og Beta-testing, men den klassifiseringen er ikke så viktig i sammenheng med typiske programvareutviklingsprosjekter i en tjenestebasert bransje.

• Alpha testing er når UAT utføres i programvarebyggerens miljø og er mer viktig i forbindelse med kommersiell programvare.
• Betatesting er når UAT utføres i produksjonsmiljøet eller klientens miljø. Dette er mer vanlig for kundevendte applikasjoner. Brukerne her er de faktiske kundene som deg og meg i denne sammenhengen.

# 5) Mesteparten av tiden i et vanlig programvareutviklingsprosjekt, blir UAT utført i QA-miljø hvis det ikke er noe iscenesettelses- eller UAT-miljø.

Kort oppsummert, den beste måten å finne ut om produktet ditt er akseptabelt og egnet for formålet, er å faktisk plassere det foran brukerne.

Organisasjoner begynner på den smidige måten å levere, forretningsbrukere blir mer involvert og prosjektene forbedres og leveres via tilbakemeldingsløkker. Når alt er gjort, betraktes brukerakseptfasen som porten for å komme i implementering og produksjon.

Hva var din UAT-opplevelse? Var du i beredskap eller testet du for brukerne dine? Fant brukerne noen problemer? Hvis ja, hvordan taklet du dem?

=> Les også ALLE veiledninger i denne serien her

=> Besøk her for komplett testplanopplæringsserie

Anbefalt lesing

• Alpha Testing og Beta Testing (En komplett guide)
• Hva er akseptantesting (en komplett guide)
• Build Verification Testing (BVT Testing) Komplett guide
• Funksjonstesting mot ikke-funksjonell testing
• Beste verktøy for testing av programvare 2021 [QA Test Automation Tools]
• Typer programvaretesting: Ulike testtyper med detaljer
• ETL Testing Tutorial Data Warehouse Testing Tutorial (En komplett guide)
• GUI Testing Tutorial: A Complete User Interface (UI) Testing Guide