Hva er brukertest (UAT): En komplett guide

Lær hva som er brukeraccepteringstest (UAT) , Sammen med definisjonen, typene, trinnene og eksemplene:

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

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

= > Klikk her for komplett testplanopplæringsserie

La oss sette dette konseptet på prøve.

= > Les alle opplæringene i vår Acceptance Testing-serie.

Hva er User Acceptance Testing?

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 beta-testing er forskjellige typer akseptantesting.

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

Når utføres den?

Dette er vanligvis det siste trinnet før produktet settes i drift eller før levering av produktet aksepteres. Dette utføres etter at selve produktet er grundig testet (dvs. etter systemtesting).

Hvem utfører UAT?

Brukere eller klienter – Dette kan være noen som kjøper et produkt ( når det gjelder kommersiell programvare) eller noen som har fått en spesialutviklet programvare gjennom en programvaretjenesteleverandør eller sluttbrukeren hvis programvaren blir gjort tilgjengelig for dem i forkant av tiden og når deres tilbakemelding blir sø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 brukertest

Utviklere og funksjonstestere er tekniske personer som validerer programvaren mot funksjonsspesifikasjonene. 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 er kun kjent for sluttbrukerne blir enten savnet å kommunisere eller feiltolkes.

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

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

Er UAT virkelig nødvendig?

Etter å ha utført masse system-, integrasjons- og regresjonstesting, vil 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, ville validere systemet for å passe det.

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

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

Følgende er forutsetningene før planleggingsfasen. begynner:

# 1) Samle nøkkelakseptkriteriene

Enkelt sagt er akseptkriterier en liste over disse selskaper 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 pga. 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 opprinnelige 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 sjelden.

(ii) Hjelp i denne testen – Mest felles. 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 bistå, dele svarene deres og registrere resultatene eller logge feil osv., Mens brukerne utfører den faktiske testen.

(iii) Utfør UAT og nåværende 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 av QA-teamet.

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

De primære målene og forventningene:

UAT utføres vanligvis 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økkelaktivitetene i hver UAT-fase er definert nedenfor:

UAT Governance

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

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

UAT-testplanlegging

Prosessen er nesten den samme som med den vanlige testplanen i systemfasen.

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

Test for test av brukeraksept

(Dette er det samme som du ville gjort finn på vår side for QA-opplæringsserien også.

Klikk på bildet nedenfor og bla ned for å finne testplanens dokumenteksempel i forskjellige formater. I den malen sjekk UAT-delen.

Datoer, miljø, aktører (hvem), kommunikasjonsprotokoller, roller og ansvar, maler, resultater og deres analyseprosess, kriterier for inngang og utgang – alt av 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ørg for at alt blir tatt med i betraktning.

= > Her er et testeksempel for brukeracceptanseplaneksempel

Test av design for brukeraksept

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 testingen.)

Testmal for brukeraksept:

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 en delmengde når vi tester alle applikasjonene i motsetning, bare til de viktigste funksjonelle områdene.

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

Testutførelse

Vanligvis, når det er mulig, skjer denne testingen i en konferanse eller et krigsrom som en slags sette opp hvor brukerne, PM, QA-teamrepresentanter alle sitter sammen en dag eller to og jobber gjennom alle aksepttesttilfellene.

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

Når alle testene er kjørt og resultatene er i hånden, tas akseptavgjørelsen. Dette kalles også Go / No-Go-avgjørelsen. Hvis brukerne er fornøyde, er det en Go, ellers er det en No-go.

Å nå akseptbeslutningen er vanligvis slutten på denne fasen.

Verktøy & Metodologier

Typen programvareverktøy som brukes i løpet av denne testfasen, ligner vanligvis på verktøyene som brukes under funksjonstesting.

Verktøy:

Ettersom denne fasen innebærer validering av hele strømmen til applikasjonen, kan det være vanskelig å ha ett verktøy for å automatisere denne valideringen fullstendig. 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øy kan konfigureres for å kumulere data for brukerakseptfasen.

Metodikk:

Selv om konvensjonelle metoder som spesifikke forretningsbrukere som utfører UAT av produktet, fremdeles er relevante, i en virkelig global i verden som i dag, må test av brukeraksept av og til involvere varierte kunder over land basert på produktet.

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

Massetesting er en metodikk der folk fra hele verden kan delta og validere bruken av produktet og gi forslag og anbefalinger.

Crowd testing plattformer 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 Methodology viser seg å være mer effektiv da pulsen til kunden over hele verden lett kan forstås.

UAT In Agile Environment

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 i oppgi krav og derved oppdatere produktets etterspørsel. I løpet av slutten av hver sprint ville bedriftsbrukere delta i sprintdemoen og være tilgjengelig for tilbakemelding.

Videre vil en UAT-fase planlegges før sprint ferdigstillelse der forretningsbrukerne ville gjøre sitt valideringer.

Tilbakemeldingene som mottas under sprintdemo og sprint UAT, blir samlet og lagt til i produktets etterspørsel som kontinuerlig 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 & 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 ved UAT Og avbøtningsplan

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

# 1) Oppsett av miljø og distribusjonsprosess:

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

Et eget produksjonslignende miljø bør settes opp 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 blir testet i den nyeste versjonen.

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

# 2) Test Planlegging:

Denne testingen bør planlegges med en klar akseptanalysetestplan 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 testen, ettersom 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 fall 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 kommuniseres til teamet i god tid før du begynner på denne testen. Dette vil hjelpe dem med testplanlegging, skriv testtilfeller & testskripter og oppretter 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 ulike interne avdelinger.

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

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

# 5) Feil kommunikasjonskanal:

Kommunikasjon mellom ekstern utvikling, testing og UAT-team er vanskeligere . E-postkommunikasjon er ofte veldig vanskelig når du har et offshore tech-team. En liten uklarhet 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 funksjoneltestteam om å utføre denne testen:

Det er ingen verre situasjon enn å be om funksjonstesten team for å 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 live, vil sluttbrukerne raskt oppdage problemene som ikke blir betraktet som virkelige scenarier av funksjonstesterne.

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

# 7) The Blame Game

Noen ganger prøver bedriftsbrukere 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 sjeldent, 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 plan for brukeraksept ved å overvinne ulike utfordringer. Riktig planlegging, kommunikasjon, utførelse og motivert team er nøklene til vellykket testing av brukeraksept.

Systemtesting Vs Brukeracceptansetest

Involveringen av testteamet starter ganske tidlig i prosjekt rett fra kravanalysefasen.

Gjennom hele prosjektets livssyklus utføres en slags validering for prosjektet, dvs. Statisk testing, Enhetstesting, Systemtesting, integrasjonstesting, en slutt-til-slutt-testing eller regresjonstesting. Dette etterlater oss til å 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 opprettholde uavhengigheten mellom begge fasene som vil gi raskere markedsføringstid.

Konklusjon

# 1) UAT handler ikke om sider, felt eller knapper. Den underliggende antagelsen allerede 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 et stykke veldig dårlige nyheter for QA-teamet. 🙁

# 2) Denne testingen handler om enheten som er det viktigste elementet i virksomheten.

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

Et annet eksempel, hvis nettstedet er et bilforhandlersted, så er fokuset på «bilen og dens salg» og egentlig ikke nettstedet. Derfor er kjernevirksomheten det som er bekreftet og validert, og hvem er bedre å gjøre det enn bedriftseiere. Det er derfor denne testingen gir mest mening når kunden i stor grad er involvert.

# 3) UAT er også en form for testing i kjernen som betyr at det er god sjanse for identifisere noen feil i denne fasen også. Det skjer noen ganger. Bortsett fra at det er en stor opptrapping i QA-teamet, betyr UAT-feilene vanligvis et møte for å sitte og diskutere hvordan de skal håndteres som følger med denne testen er det vanligvis ikke tid til å fikse og teste på nytt.

Avgjørelsen er å enten:

• Trykk på go-live-datoen, fikse problemet først og deretter gå videre.
• 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 industri.

• Alfa-testing er når UAT utføres i programvarebyggerens miljø og er mer viktig i sammenheng med kommersiell hylle 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øet hvis det er ingen iscenesettelse eller UAT-miljø.

Kort fortalt er den beste måten å finne ut om produktet ditt er akseptabelt og egnet for formålet, å 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 fullstendig opplæringsserie for testplan