Hvordan til at Gennemføre Brugernes Accept Test: Proces, Faser, Resultater og End-User Test Sted i Kvalitetssikring

Læsning tid: 14 minutter

for At sikre den tekniske kvalitet af et produkt, for at finde fejl og logiske fejl i software, er det vigtigt at engagere sig i kvalitetssikring. Kvalitetstest vil dog ikke fortælle dig, om slutproduktet er tilpasset forretningsmål og kan udføre nødvendige opgaver i virkelige scenarier. Så for at sikre, at udviklingsteamet bygger det rigtige produkt til de faktiske slutbrugere, er det vigtigt at udføre test af brugeraccept.

hvad er test af brugeraccept, og hvordan adskiller det sig fra kvalitetssikring?

User Acceptance Testing (UAT) kontrollerer, om et produkt er det rigtige for slutbrugerne. Slutbrugertest, operationel, applikation, beta-test eller validering, men de beskriver det samme. I kvalitetssikring er det vigtigt at skelne mellem validering og verifikation.

verifikation henviser til generelle kvalitetssikringsprocesser, der har til formål at teste de tekniske aspekter af et produkt for at sikre, at det rent faktisk fungerer. Validering (eller test af brugeraccept) udføres for at sikre, at produktet svarer til forretningskrav og kan bruges af slutbrugeren.

validerings-og verifikationsaktiviteter med hensyn til samlet produkttest

Valideringsaktivitet kan opdeles i to typer test.

alfa-test er den indledende fase af accepttestning, typisk udført af interne testere, for at sikre, at produktet fungerer korrekt og opfylder forretningskrav.

Beta-test, den anden type accepttest, sigter mod at opfylde brugernes acceptkriterier. UAT kan udføres af

• de faktiske brugere af et eksisterende produkt,
• brugere af en tidligere version af et produkt,
• interessenter involveret i udviklingen af produktet og/eller
• forretningsanalytikere som slutbrugerspecialister.

dette gør det muligt for udviklingsteamet at løse de fleste af brugervenlighedsproblemer, fejl og uventede problemer vedrørende funktionalitet, systemdesign, forretningskrav osv.

Hvorfor har du faktisk brug for UAT?

hovedformålet med accepttest er at validere, at produktet svarer til brugernes behov (defineret på produktopdagelsesstadiet) og er klar til lancering. Ifølge en Origsoft-undersøgelse om UAT-brug sagde over 75 procent af de adspurgte, at de udfører flere cyklusser med slutbrugertest med 57 procent, der hævder produktets dårlige kvalitet som en grund.

så her er de vigtigste grunde til, at UAT er vigtig og bør være en del af din udvikling.

sørg for korrespondance med forretningskrav. Som vi allerede har nævnt, er UAT gjort for at kontrollere, at produktet fungerer under de virkelige omstændigheder efter behov og giver slutbrugerne mulighed for at løse målrettede problemer. Hvis du springer over UAT, kan du gå glip af nogle vigtige fejl eller systemfejl, der uundgåeligt vil medføre brugernes utilfredshed.

Juster de oprindelige krav. Nogle gange, når slutbrugere tester produktet, kan de komme med nogle værdifulde tanker om, hvordan man forbedrer det testede program. At få sådan feedback giver dig mulighed for at justere dine krav for at få et resultat, der vil være mere nyttigt for dine kunder.

undgå tab. For det første er det billigere at reparere produktet i de tidlige udviklingsstadier, så at finde fejl på grund af UAT vil give dit udviklingsteam mulighed for at forbedre produktet meget lettere (det drejer sig dog mest om den Agile model. Læs videre for flere detaljer). For det andet kender vi alle historier om produktfejl på grund af dårlig funktionalitet og brugervenlighed. UAT giver dig den virkelige verden brugerfeedback og gør det langt mindre tilbøjelige til at have tab forårsaget af en mislykket produktlancering.

under alle omstændigheder kræver UAT organisations-og forberedelsesarbejde for at gøre det effektivt. Hvis du vil sikre dit produkts gyldighed, skal du overveje følgende trin i gennemførelsen af test af brugeraccept.

UAT-nøglefaser

analyser produktkrav og definer nøgleleverancer

analyse af produktkrav er det første trin i UAT-planlægning. Den primære kilde til inputinformation ville være specifikationen for programmelkrav, da den inkluderer det komplette omfang af forretnings-og funktionelle krav.

forretningskrav er de høje mål for din organisation, der kommunikerer forretningsbehov. Det kan lyde som “kunder skal kunne bruge flere betalingsmetoder.”

funktionelle krav bygger bro over en teknisk løsning med forretningskravene. Så det funktionelle krav lyder som ” implementer PayPal, Visa og Mastercard, Payoneer betalingsportaler.”

oversigten over disse krav fortæller dig nøjagtigt, hvad du skal teste, om de implementerede løsninger fungerer for brugerne og løser problemer for virksomheden. Funktionelle krav kan oversættes til testsager under hensyntagen til succeskriterierne for forretningskrav. Og det vil hjælpe dig med at danne en samlet teststrategi. Overvej at engagere dine forretningsanalytikere, KVALITETSSIKRINGSINGENIØRER eller produktejere til kravanalyse.

den endelige planlægningsfase skaber teknisk dokumentation til UAT-processen. Her dokumenterer du din teststrategi, regler, testscenarier/cases, standarder osv. I de følgende afsnit beskrives den dokumentation, der anvendes i test af brugeraccept.

bruger accept test leverancer

UAT testplan. Oprettelse af en UAT-testplan hjælper dig med at holde alle på linje med de samme mål og vision. Hoveddokumentet indeholder alle oplysninger om, hvad der skal testes, af hvem og hvordan. For at dække alle de organisatoriske og processuelle aspekter af UAT skal du specificere teststrategien og indgangs – /udgangskriterierne.

slutbruger teststrategi. Strategien skitserer det produkt, du tester, formålet med test af brugeraccept, typer af tests og mål. Din teststrategi skal dække sådanne oplysninger som

• produktbeskrivelse,
• testmål,
• testomfang,
• standarder,
• testtyper,
• testere/roller
• process curators (managers),
• anmeldere,
• rapporteringsstandarder og
• resultater.

adgangskriterier. Dette er de betingelser, der fastslår, at programmet er klar til at blive testet. De er sat i den tidligste fase af planlægningen af udviklingsteamet, kvalitetssikring, forretningsanalytikere, og interessenter.

afslutnings-eller acceptkriterier. Dette er de betingelser, der dikterer, at programmet er gyldigt for brugerne. Matchende acceptkriterier ville være den sidste fase af din UAT.

testscenarier. Testscenarier er hypotetiske situationer, som brugerne kan støde på, når de interagerer med dit produkt. Deres mål er at guide dine testere gennem mulige systembrugsproblemer.

grundlæggende skal et testscenarie formidle en simpel ide om, hvad der skal testes. Et eksempel på et scenario er “check indkøbskurv funktionalitet.”Hvert brugerscenarie er forbundet med et eller to krav eller brugerhistorier. De er skrevet for at validere, at systemet er brugbart, kontrollere end-to-end operationer med reelle data.

hvis du vil skrive gode testscenarier til test af brugeraccept, skal du overveje at involvere slutbrugere i godkendelse for at inkludere alle mulige brugssager, både almindelige og usædvanlige. Overvej også at skrive dem på almindeligt sprog og undgå kompliceret formulering eller alt for tekniske forklaringer.

testsager. En testsag er et sæt specifikke handlinger, der udføres for at teste og verificere en bestemt systemadfærd, funktion eller funktionalitet. Testcases er mere detaljerede enheder, der skal svare til alle testscenarierne. Oftest vil du konvertere dine brugerhistorier og business use cases til at skrive effektive testcases. Eksempler på testsager er:

1. Check uregistreret bruger tilføje produktet i indkøbskurven.
2. Tjek indkøbskurv filtrering.
3. kontroller knappen “Fortsæt shopping”.

testcases er effektive, når der er et klart formål angivet, og brugeren er i stand til at forstå, hvad de skal gøre for at fuldføre det. Brugervejledningen til en testsag kan se sådan ud:

1. Åbn applikationen.
2. Føj ethvert produkt til en indkøbskurv.
3. godkendelse er ikke nødvendig.
4. fortsæt til indkøbskurven.

du kan også medtage forventede resultater i testsagen, så brugeren er opmærksom på, hvad der skal ske:

1. produktet vises i en indkøbskurv.
2. systemet vil bede dig om at godkende som registreret bruger.

rapporteringsstandarder. Definer, hvordan en rapport skal se ud, og hvilke oplysninger en slutbruger skal give.

testrapporter. Disse akkumulerer dokumenterede outputdata, når testen er afsluttet. Afhængigt af teststandarderne og testscenariet kan forskellige oplysninger indgå i rapporter. Men typisk i UAT kræver KVALITETSSTYRINGSHOLD kun en sign-off fra testeren. En sign-off er blot en bekræftelse på, at testen er vellykket, og det svarer til brugerens kriterier.

i slutningen af UAT kan leverede leverancer bruges af kvalitetsingeniører eller en UAT-manager til at udtrække værdifulde data og kommunikere resultater til udviklingsholdet.

traditionelt vil kvalitetssikringsingeniører være ansvarlige for behandling af slutbrugerfeedback. Resultaterne af test, fejlrapporter og fail/pass-poster leveres til udviklere for at sikre konstant kommunikation mellem forskellige dele af teamet. Baseret på slutbrugerens feedback kan KVALITETSSIKRINGSTEAMET også levere kvalitetsmålinger til måling af fremskridt med hensyn til UAT.

skabeloner til test af brugeraccept

vi har nævnt et par vigtige dokumenter, der skal oprettes for korrekt UAT-planlægning og udførelse. Der er forskellige måder at skrive dem på, men her er nogle skabeloner, der kan være nyttige.

• testplanskabeloner: Testplanskabelon af Coley Consulting, sfsu-skabelon (link til hentning) eller iiba-skabelon (link til hentning)
• testscenarie skabelon

Vælg tid og form for slutbrugertest

accepttest kan finde sted på forskellige stadier af projektet, afhængigt af den metode, du bruger, men typisk udføres den i slutningen af projektet udviklingscyklussen før frigivelse. Da to af de mest populære projektstyringsmetoder inden for programudvikling er Vandfald og Agile, vil vi se på testprocessen for brugeraccept inden for disse to modeller.

accepttest i vandfaldsmodellen

for at dykke dybere ned i detaljerne skal vi hurtigt sammenfatte, hvad en vandfaldsmodel er. Det er en traditionel projektledelsesmetode baseret på en trinvis udvikling af produktet.

stadierne krydser ikke hinanden, hvilket betyder, at der ikke er nogen samtidig design-og designtest eller udvikling og test. Hele processen er strengt dokumenteret og beregnet til at levere en fuldt funktionel applikation i slutningen af udviklingen uden iterationer.

Brugeracceptfase inden for vandfaldsmodellen

Brugeraccepttest i vandfald finder sted i det sidste udviklingsstadium lige før lanceringen.

det kan kun udføres, efter at systemet betragtes som kode og funktion klar, efter at have opnået følgende benchmarks.

• produkt forretningskrav er opfyldt.
• kodebasen er færdig.
• KVALITETSAKTIVITETER (system, integration, enhedstest) er afsluttet.
• fejl afsløret under KVALITETSSIKRINGSFASEN er blevet rettet.
• Mindre visuelle problemer er i et acceptabelt interval.
• Brugeracceptmiljø (UAT manager, værktøjer til test, testscenarier osv.) er skabt .

i vandfaldsmodellen er test af brugeraccept det endelige punkt, der viser programmelberedskab. Hvis et produkt opfylder brugernes acceptkriterier, betyder det, at produktet er klar til produktion. UAT-aktiviteter er i så fald til at gennemføre systemcheck, dets funktionalitet, brugervenlighed og fejl. Men det primære mål er stadig at sikre, at produktet svarer til de oprindelige krav og slutbrugerens behov.

brugeraccept i Agile metoder

den Agile model for programmeludvikling er ikke så ligetil som vandfald. Det er baseret på at gentage hvert udviklingsstadium, indtil produktet når den krævede kvalitet og funktionalitet. Iterationer af hver fase giver mulighed for meget fleksibel udvikling og dynamisk ændring i krav, da Agile ikke fokuserer på at skabe meget dokumentation. Og det gør det muligt for udviklingsteamet hurtigt at reagere på skiftende krav fra kunden.

Brugeraccepttest i Agile model

billedet viser den Agile produktudviklingscyklus med iterationer. Du kan gennemføre test af brugeraccept på hvert trin i projektet for at sikre produktets gyldighed. Den største forskel mellem UAT i Vandfald og i Agile er, at UAT udføres flere gange (ofte inden for hver iteration), og dens resultater kan påvirke de oprindelige krav, da det leverer øjeblikkelig feedback om, hvad der fungerer bedst.

kontrolpunkterne for start af slutbrugertest i et agilt projekt er

• dannede forretningskrav,
• dokumentationssystem,
• testmateriale (interaktive mock-ups, high-fidelity prototyper, demoer) og
• brugeracceptmiljø.

i Agile er UAT en integreret del af de samlede testaktiviteter, så det kan tage forskellige former og bruge forskellige værktøjer. For eksempel kan disse være test på funktionelle og ikke-funktionelle krav eller test i tidlig fase for at validere antagelser foretaget i planlægningsfasen. I slutningen af hver iteration producerer accepttest leverancer, der bruges til at ændre krav, systemarkitektur, UC-stilguider osv.

rekrutter brugere og form UAT team

som vi nævnte tidligere, kan testere rekrutteres fra din eksisterende brugerbase. Afhængigt af projektets specifikationer kan disse være emneeksperter, virkelige brugere af produktet, interessenter, forretningsanalytikere, produktejer eller kunden. Du kan også bruge menneskemængde-sourcing platforme til at søge efter testere eller ansætte en freelance bruger-Test specialist.

overvej at oprette en besked på sociale medier eller endda en destinationsside for at tiltrække et publikum. Dine potentielle testere skal ikke nødvendigvis være teknisk kyndige eller fortrolige med testprocesser. Dem, der allerede har eller vil bruge dit produkt (eller måske et lignende), vil dog være gode kandidater til din UAT, da du i så fald kan undgå dyb onboarding og KVALITETSTEAMINDDRAGELSE.

Implementer slutbrugertestværktøjer og testere ombord

selvfølgelig er der specifikke instrumenter på markedet, der er designet til slutbrugertest. De mest populære værktøjer tilbyder teststyringsfunktionalitet som rapportering, opgaveoversigter og testdokumentationsskabeloner. Her er nogle eksempler på programmer, der kan bruges til at understøtte dine UAT-aktiviteter.

Usersnap er en populær platform til at give visuel feedback på de testede programmer og internetbaserede applikationer. Dybest set er det et værktøj, der giver brugerne mulighed for at markere fejlene lige på skærmen, efterlade kommentarer og forslag og dele feedbacken. Der er mange lignende instrumenter som Userback og UserTesting.

FitNesse er en open source-drevet ramme for accept test automatisering. Det giver alle interessenter mulighed for nemt at oprette, redigere og køre tests, hvilket skaber tidlig feedback. Brugere indtaster specielt formaterede indgange til automatisk at generere tests, der straks køres af systemet. Derefter returneres output og fremhæves afhængigt af om det matcher det forventede resultat eller ej. Denne samarbejdsplatform har en mild indlæringskurve og er populær blandt Agile teams.

Bugulv er et andet instrument til udførelse af UAT. Udover at teste miljø og fejlrapportering tilbyder det gamification og konkurrencefunktioner til at motivere og engagere brugere. Du finder også nyttige indbyggede betalingsmuligheder, hvis du skal udføre slutbrugertest online.

velkendte projektstyringsværktøjer som Jira eller Trello har også funktionalitet til at udføre uat.

Testing dashboard i SpiraTest

Opret brugeracceptmiljø og kør træning

for at få mest muligt ud af slutbrugertest, start med træningen. Dine testere og UAT-manager er ansvarlige for det. Overvej at strukturere din træningsproces til at omfatte følgende aspekter.

• Introducer brugerne til testprocessen og dens mål.
• træn brugere til at bruge værktøjer til slutbrugertest, hvis du vil bruge dem.
• giv dem rapporteringsstandarder og retningslinjer.
• sørg for, at brugerne forstår testcases korrekt og yder support, hvis det er nødvendigt.
• giv dem adgang til testmiljøet.

oftest kan slutbrugertest udføres på brugerens side, hvilket betyder, at du ikke behøver at forsyne dine testere med udstyret. Hele processen kan også gøres online. Mere komplicerede projekter eller fortrolige data kan kræve indsamling af et dedikeret team af brugertestere på dit kontor. Det er også vigtigt at udpege en leder, der skal levere dokumentation, værktøjer og support.

Kør testene

når du har dine testscenarier og testcases, er du god til at gå med testene. For at støtte dine slutbrugere under processen og få de krævede resultater, levere en klar forståelse af, hvilke handlinger hver testsag kræver. Husk, at dine brugere ikke er professionelle testere. Under testen skal du sørge for at levere reelle eller tæt på reelle data til brugerne og undgå prøveindhold eller dummy-knapper. Enhver misforståelse kan få dem fast i testsagen.

et andet vigtigt aspekt er at have dine udviklere klar til at rette noget, der går galt. Dit testmiljø kan lukke ned, eller der kan være fejl, der forhindrer brugere i at teste. Brugere skal kunne få adgang til den krævede funktionalitet på hvert trin i testningen, hvad enten det er et interaktivt design eller en funktionel app, for at give dem mulighed for at udføre hver testsag, der er inkluderet i testplanen.

Saml outputoplysninger og analyser det

under dine UAT-aktiviteter får du masser af data fra testerne. Dit team skal analysere det. Dataene indsamles via brugerrapporter indsendt manuelt eller via et specifikt værktøj. Derudover kan du gennemføre samtaler med separate brugere for at få mere indsigt i de testsager, de udførte, og hvad de synes om dem.

for at evaluere systemberedskab skal du overveje at måle procentdelen af test, der er bestået/mislykkedes/rettet.

Test tracking dashboard i Panaya

der er også et par flere punkter, der bør overvejes:

systemstabilitet. Stabilitet kan bestemmes af antallet af uventede fejl opfyldt under UAT.

dækning af test. Dækningen måles ved antallet af testscenarier/sager skrevet og deres forhold til de samlede færdige tests. Du kan også matche dine UAT-testresultater med brugerrejsekortet for at forstå, hvilken del af funktionaliteten der ikke blev testet.

anvendelighed af systemet. Dette kan beregnes ved antallet af test, der ikke er bestået, fordi brugeren ikke fandt en måde at gøre det på. Men den samlede bruger testes under brugbarhedstest, som udføres som en separat aktivitet.

kontrakt/krav overholdelse. Kravoverholdelse kontrolleres, når alle slutbrugertestene er afsluttet. Det sikrer, at programmelopbygningen stadig svarer til de oprindelige krav/kontraktomfang, selv efter ændringer, der er forårsaget af brugeraccept.

Ret fejl, retest og sign-off

efter udførelse af UAT skal alle fejl dokumenteres med relevante kommentarer og sendes til udviklingsteamet. De skal foretage justeringer af koden for at løse de problemer, der er afsløret af uat.

når du har rettet fejlene, skal du prøve dem igen for at sikre, at alt fungerer korrekt. Når acceptkriterierne nås og godkendes af korrekturlæsere, træffes den endelige acceptbeslutning om produktets produktionsberedskab.

UAT-teamroller

som vi nævnte tidligere, er UAT-test forskellig fra andre KVALITETSSIKRINGSAKTIVITETER, fordi den ikke kun udføres af tekniske specialister; det er også vigtigt at engagere faktiske slutbrugere i denne proces. Det er også nødvendigt at involvere kvalitetssikrede fagfolk og forretningsanalytikere, ligesom det er tæt samarbejde med projektlederen og udviklingsholdet.

UAT-teamets ansvar kan variere afhængigt af virksomhedens og projektbehovet, men her er et eksempel på den rollefordeling, du kan overveje.

Business program manager. Dette er den person, der koordinerer og fører tilsyn med hele projektet og tilpasser det til forretningsmål. Før UAT-scenen skal programlederen generere programleveringsplanen og forretningskravsdokumentet for at understøtte testaktiviteterne. Han / hun er også ansvarlig for at gennemgå og godkende testplanen og teststrategien.

under UAT overvåger programlederen udførelse af testaktiviteter og sikrer færdiggørelse efter tidsplan og budget. Derefter gennemgår han / hun testrapporten og beslutter om implementering til produktion.

UAT test lead/manager. Testlederens ansvar er at planlægge og organisere UAT nøjagtigt. Til dette kræves normalt et tæt samarbejde med projektlederen.

testlederen samler og analyserer alle de forretnings-og funktionelle krav, der derefter bruges til at udvikle den nødvendige dokumentation, dvs.teststrategi, testplan, testscenarier osv. Derudover arbejder han/hun i forberedelsesfasen med testteamet, tildeler testscenarier til teammedlemmer og organiserer træning for at sikre, at testere forstår UAT-proceduren. Testledningen forbereder og administrerer også de nødvendige ressourcer og indlæser vigtige testdata i testværktøjer.

i hele UAT koordinerer ledelsen udførelsen af testsager og sørger for, at alle testresultater dokumenteres. Han/hun sporer også testfremskridt, indsamler målinger og opretter / vedligeholder en testrapport.

UAT test teammedlemmer. Testholdets hovedopgave er at udføre test i overensstemmelse med den angivne tidsplan og instruktioner. Testere skal oprette testlogfiler og rapportere om fejl og hændelser. De deltager også typisk i genprøvningsaktiviteter (hvis nødvendigt).

projektlederen, som den person, der er ansvarlig for en vellykket projektafslutning, skal overvåge testaktiviteter, yde organisatorisk support og rapportere om fremskridt. Han / hun ville også fungere som mægler mellem testteamet, udviklere, kunde og andre mulige interessenter.

UAT-tjekliste

opsummering af UAT-retningslinjerne, vi præsenterede ovenfor, har vi udviklet en tjekliste, der hjælper dig med at organisere dine testaktiviteter og ikke gå glip af noget vigtigt.

initiering af UAT-projektet.

1. Bekræft med dit udviklingsteam, at alle produktkomponenter er klar til test. Dokumenter eventuelle problemer, der ikke kunne løses før UAT.
2. Identificer de vigtigste interessenter.
3. vælg en teamleder, der er ansvarlig for projektet, herunder papirarbejde.
4. diskutere og blive enige om projektstrukturen, UAT-teamet og UAT-dokumentationen.
5. grundigt diskutere testprocedurerne og oprette en indledende UAT-plan.

planlægning UAT.

1. Opret dit UAT-team, og sørg for, at du har testere fra hvert markedssegment og/eller hver gruppe af interessenter. Vær sikker på, at al deltagelsesrelateret dokumentation er komplet og underskrevet (ikke-offentliggørelse, deltagelsesaftale osv.).
2. Kommuniker teststrategien og tidsplanen til teamet. Sørg for, at hvert medlem forstår rollerne, procedurer, og ansvar.
3. sørg for, at alle forretningskrav er fanget og kommunikeret til UAT-teamet.
4. diskutere og blive enige om Ind-og udrejsekriterier.
5. Forbered al forretningsdokumentation: testplan, testscenarier, testcases osv.
6. Kommuniker virksomhedens mål og accept/udgangskriterier for systemet.
7. er enige om rapporteringsstandarder.
8. udfør den nødvendige træning på systemet og hjælpeværktøjer. Sørg for, at testerne forstår, hvordan man rapporterer hændelser.
9. Saml og forbered alle de nødvendige ressourcer til UAT-aktiviteter. Book plads, hvis det er nødvendigt.
10. Forbered og test miljøet, teststyringsværktøjer, enheder, servere, feedbackkanaler, problemsporing, levering af indhold osv.
11. sørg for, at du har alle logins, at sikkerhedsadgang er konfigureret, og testdata er indlæst.

udførelse af UAT.

1. Overvåg, hvordan procedurer udføres, og sørg for, at rapporter indsendes rettidigt og nøjagtigt.
2. Opret og vedligehold testoversigtsrapporten.

post-UAT aktiviteter.

1. analyser outputinformationen ved at måle procentdelen af test, der bestod/mislykkedes, samt kategorisere defekter efter sværhedsgrad.
2. Identificer status mod acceptkriterier.
3. Forbered den endelige UAT-rapport og præsentere den for interessenter sammen med estimeret tid og kræfter, der kræves for at opfylde acceptkriterier og anbefalinger til frigivelse.

testprocedurer kan variere fra virksomhed til virksomhed. Her er et par andre UAT-tjeklister, der kan hentes, der også passer til dine behov: tjekliste 1, tjekliste 2.