hur man genomför User Acceptance Testing: Processstadier, leveranser och Slutanvändartestning plats i kvalitetssäkring

innehåll

lästid: 14 minuter

för att säkerställa de tekniska egenskaperna hos en produkt, för att hitta buggar och logiska misstag i programvaran är det viktigt att engagera sig i kvalitetssäkringsaktiviteter. QA-testning kommer dock inte att berätta om slutprodukten är anpassad till affärsmålen och kan utföra nödvändiga uppgifter i verkliga scenarier. Så för att säkerställa att utvecklingsteamet bygger rätt produkt för de faktiska slutanvändarna är det viktigt att genomföra användaracceptprovning.

vad är användaracceptprovning och hur skiljer det sig från kvalitetssäkring?

User Acceptance Testing (UAT) kontrollerar om en produkt är den rätta för slutanvändarna. Den har andra namn, t.ex. slutanvändartestning, Drift, applikation, betatestning eller validering men de beskriver samma sak. I kvalitetssäkring är det viktigt att skilja mellan validering och verifiering.

verifiering avser allmänna QA-processer som syftar till att testa de tekniska aspekterna av en produkt för att säkerställa att den faktiskt fungerar. Validering (eller användaracceptprovning) utförs för att säkerställa att produkten överensstämmer med affärskraven och kan användas av slutanvändaren.

testtyper

validerings-och verifieringsaktiviteter när det gäller övergripande produkttestning

Valideringsaktivitet kan delas in i två typer av testning.

alfa-testning är det första steget i acceptanstestning, som vanligtvis utförs av interna testare, för att säkerställa att produkten fungerar korrekt och uppfyller affärskraven.

Beta-testning, den andra typen av acceptanstestning, syftar till att uppfylla användaracceptkriterier. UAT kan utföras av

  • de faktiska användarna av en befintlig produkt,
  • användare av en tidigare version av en produkt,
  • intressenter som är involverade i utvecklingen av produkten och/eller
  • affärsanalytiker som slutanvändarspecialister.

detta gör det möjligt för utvecklingsteamet att fixa de flesta användbarhetsproblem, buggar och oväntade problem som rör funktionalitet, systemdesign, affärskrav etc.

Varför behöver du faktiskt UAT?

huvudsyftet med acceptanstestning är att validera att produkten motsvarar användarnas behov (definierad vid produktupptäcktsstadiet) och är redo för lansering. Enligt en Origsoft-undersökning om UAT-användning sa över 75 procent av de svarande att de utför flera cykler av slutanvändartestning med 57 procent som hävdar produktens dåliga kvalitet som en anledning.

så här är de främsta anledningarna till att UAT är viktigt och bör vara en del av din utveckling.

säkerställa korrespondens med affärskrav. Som vi redan nämnde är UAT gjort för att verifiera att produkten fungerar i de verkliga omständigheterna efter behov och tillåter slutanvändare att lösa riktade problem. Om du hoppar över UAT kan du missa några viktiga brister eller systemfel som oundvikligen kommer att orsaka användarens missnöje.

justera initiala krav. Ibland, när slutanvändare testar produkten, kan de komma med några värdefulla tankar om hur man kan förbättra den testade programvaran. Att få sådan feedback gör att du kan justera dina krav för att få ett resultat som blir mer användbart för dina kunder.

Undvik förluster. För det första är det billigare att fixa produkten i de tidiga utvecklingsstadierna, så att hitta brister på grund av UAT gör det möjligt för ditt utvecklingsteam att förbättra produkten mycket lättare (det gäller mestadels den smidiga modellen. Läs vidare för mer information). För det andra vet vi alla historier om produktfel på grund av dålig funktionalitet och användbarhet. UAT ger dig feedback från verkliga användare och gör det mycket mindre sannolikt att ha förluster orsakade av en misslyckad produktlansering.

i alla fall kräver UAT organisation och förberedelsearbete för att göra det effektivt. Om du vill säkerställa produktens giltighet bör du överväga följande steg när du utför test av användaracceptans.

UAT-steg

UAT-nyckelsteg

analysera produktkrav och definiera viktiga leveranser

analysera produktkrav är det första steget i UAT-planeringen. Den primära källan till inmatningsinformation skulle vara specifikationen för programvarukrav eftersom den innehåller hela omfattningen av affärs-och funktionskrav.

affärskrav är de höga målen för din organisation som kommunicerar affärsbehov. De kan låta som ” kunder ska kunna använda flera betalningsmetoder.”

funktionella krav överbryggar en teknisk lösning med affärskraven. Så det funktionella kravet skulle låta som ” implementera PayPal, Visa och Mastercard, Payoneer payment gateways.”

översikten över dessa krav kommer att berätta exakt vad du ska testa, om de implementerade lösningarna fungerar för användarna och löser problem för verksamheten. Funktionella krav kan översättas till testfall, med tanke på framgångskriterierna för affärskrav. Och det hjälper dig att bilda en övergripande teststrategi. Överväg att engagera dina affärsanalytiker, QA-ingenjörer eller produktägare för kravanalys.

det slutliga planeringsstadiet är att skapa teknisk dokumentation för UAT-processen. Här dokumenterar du din teststrategi, regler, testscenarier/fall, standarder etc. Följande avsnitt beskriver dokumentationen som används vid testning av användaracceptans.

Användaracceptprovningsleveranser

UAT-testplan. Att skapa en UAT-testplan hjälper dig att hålla alla i linje med samma mål och vision. Huvuddokumentet innehåller all information om vad som ska testas, av vem och hur. För att täcka alla organisatoriska och processuella aspekter av UAT måste du specificera teststrategin och in – /utgångskriterierna.

slutanvändarens teststrategi. Strategin beskriver den produkt du testar, syftet med testning av användaracceptans, typer av tester och mål. Din teststrategi bör omfatta sådan information som

  • produktbeskrivning,
  • testmål,
  • testomfång,
  • standarder,
  • testtyper,
  • testare/Roller
  • process curatorer (Chefer),
  • granskare,
  • rapporteringsstandarder och
  • resultat.

inträdeskriterier. Det här är de villkor som fastställer att programvaran är redo att testas. De sätts i det tidigaste planeringsstadiet av utvecklingsteamet, QA, affärsanalytiker och intressenter.

Exit-eller acceptanskriterier. Dessa är de villkor som dikterar att programvaran är giltig för användarna. Matchande acceptanskriterier skulle vara det sista steget i din UAT.

testscenarier. Testscenarier är hypotetiska situationer som användare kan stöta på när de interagerar med din produkt. Deras mål är att vägleda dina testare genom möjliga problem med systemanvändning.

i grund och botten bör ett testscenario förmedla en enkel uppfattning om vad som ska testas. Ett exempel på ett scenario är ” kontrollera kundvagnsfunktionen.”Varje användarscenario är kopplat till ett eller två krav eller användarhistorier. De är skrivna för att validera att systemet är användbart, kontrollera end-to-end-operationerna med verkliga data.

för att skriva bra testscenarier för användaracceptprovning, överväg att involvera slutanvändare i godkännande för att inkludera alla möjliga användningsfall, både vanliga och ovanliga. Också, överväga att skriva dem i klartext, undvika komplicerade frasering eller alltför techy förklaringar.

testfall. Ett testfall är en uppsättning specifika åtgärder som vidtas för att testa och verifiera ett visst systembeteende, funktion eller funktionalitet. Testfall är mer detaljerade enheter som måste motsvara alla testscenarier. Oftast konverterar du dina användarhistorier och affärsanvändningsfall för att skriva effektiva testfall. Exempel på testfall är:

  1. kontrollera oregistrerad användare lägga produkten i kundvagnen.
  2. kontrollera kundvagn filtrering.
  3. kontrollera knappen ”Fortsätt handla”.

testfall är effektiva när det finns ett tydligt syfte och användaren kan förstå vad de ska göra för att slutföra det. Användarhandboken till ett testfall kan se ut så här:

  1. Öppna applikationen.
  2. Lägg till en produkt i en kundvagn.
  3. autentisering behövs inte.
  4. fortsätt Till kundvagnen.

du kan också inkludera förväntade resultat i testfallet, så att användaren är medveten om vad som kommer att hända:

  1. produkten kommer att visas i en kundvagn.
  2. systemet kommer att be dig att godkänna som registrerad användare.

rapporteringsstandarder. Definiera hur en rapport ska se ut och vilken information en slutanvändare ska tillhandahålla.

testrapporter. Dessa ackumulerar dokumenterade utdata när testet är klart. Beroende på teststandarder och testscenario kan olika uppgifter inkluderas i rapporter. Men vanligtvis i UAT kräver QA-team bara en sign-off från testaren. En sign-off är bara en bekräftelse på att testet är framgångsrikt och det motsvarar användarens kriterier.

i slutet av UAT kan leveranser som tillhandahålls användas av QA-ingenjörer eller en UAT-chef för att extrahera värdefulla data och kommunicera resultat till utvecklingsteamet.

traditionellt kommer kvalitetssäkringsingenjörer att ansvara för bearbetning av slutanvändarnas feedback. Resultaten av tester, felrapporter och fail/pass-poster ges till utvecklare för att säkerställa konstant kommunikation mellan olika delar av teamet. Baserat på slutanvändarens feedback kan QA-teamet också tillhandahålla mätvärden för programkvalitet för att mäta framsteg när det gäller UAT.

mallar för användaracceptprovning

vi har nämnt några viktiga dokument som måste skapas för korrekt UAT-planering och utförande. Det finns olika sätt att skriva dem, men här är några mallar som kan komma till nytta.

  • mallar för testplaner: Testplan Mall av Coley Consulting, sfsu Mall( nedladdningsbar länk), eller iiba Mall (nedladdningsbar länk)
  • testscenario Mall
  • testrapportmall

Välj tid och form för slutanvändartestning

Acceptanstestning kan ske i olika stadier av projektet, beroende på vilken metod du använder, men vanligtvis utförs det i slutet av utvecklingscykeln innan det släpps. Eftersom två av de mest populära projektledningsmetoderna inom mjukvaruutveckling är Vattenfall och Agile, kommer vi att titta på testprocessen för användaracceptans inom dessa två modeller.

acceptanstest i vattenfallsmodellen

för att dyka djupare in i detaljerna måste vi snabbt sammanfatta vad en vattenfallsmodell är. Det är en traditionell projektledningsmetodik baserad på en steg-för-steg-utveckling av produkten.

stegen skär inte, vilket innebär att det inte finns någon samtidig design och designtestning eller utveckling och testning. Hela processen är strikt dokumenterad och avsedd att leverera en fullt fungerande applikation I slutet av utvecklingen utan iterationer.

 uat i vattenfallsmodellen

användaracceptstadium inom vattenfallsmodellen

Användaracceptprovning i Vattenfall sker i slutstadiet av utveckling, precis före lanseringen.

det kan utföras först efter att systemet anses vara kod och funktion redo, efter att ha uppnått följande riktmärken.

  • produkt affärskrav har uppfyllts.
  • kodbasen är klar.
  • QA-aktiviteter (system, integration, enhetstestning) har slutförts.
  • buggar avslöjade under QA-scenen har åtgärdats.
  • mindre visuella problem ligger inom ett acceptabelt intervall.
  • Användaracceptmiljö (UAT-chef, verktyg för testning, testscenarier etc.) är skapad.

i vattenfallsmodellen är användaracceptprovning den definitiva punkten som visar programvarans beredskap. Om en produkt uppfyller användaracceptskriterierna betyder det att produkten är klar för produktion. UAT-aktiviteter är i så fall för att slutföra systemkontrollen, dess funktionalitet, användbarhet och buggar. Men det primära målet är fortfarande att säkerställa att produkten motsvarar de ursprungliga kraven och slutanvändarens behov.

användaracceptans i smidiga metoder

den smidiga modellen för mjukvaruutveckling är inte lika enkel som Vattenfall. Det bygger på att iterera varje utvecklingsstadium tills produkten når önskad kvalitet och funktionalitet. Iterationer i varje fas möjliggör mycket flexibel utveckling och dynamisk förändring av krav, eftersom Agile inte fokuserar på att skapa mycket dokumentation. Och det gör att utvecklingsteamet snabbt kan svara på förändrade krav från kunden.

uat i agile

användaracceptprovning i Agile modell

bilden visar den Agila produktutvecklingscykeln med iterationer. Du kan genomföra användaracceptprovning i varje steg i projektet för att säkerställa produktens giltighet. Huvudskillnaden mellan UAT i vattenfall och i Agile är att UAT utförs flera gånger (ofta inom varje iteration) och dess resultat kan påverka de ursprungliga kraven, eftersom det ger omedelbar feedback om vad som fungerar bäst.

kontrollpunkterna för att starta slutanvändartestning i ett agilt projekt är

  • formade affärskrav,
  • UX/systemdokumentation,
  • testmaterial (interaktiva mock-ups, high-fidelity-prototyper, demos) och
  • användaracceptmiljö.

i Agile är UAT en integrerad del av övergripande testaktiviteter, så det kan ta olika former och använda olika verktyg. Det kan till exempel vara tester på funktionella och icke-funktionella krav eller tidiga tester för att validera antaganden som gjorts under planeringsstadiet. I slutet av varje iteration producerar acceptanstestning leveranser som används för att ändra krav, systemarkitektur, UX-stilguider etc.

rekrytera användare och bilda UAT-team

som vi nämnde tidigare kan testare rekryteras från din befintliga användarbas. Beroende på projektspecifikationerna kan de vara ämnesexperter, verkliga användare av produkten, intressenter, affärsanalytiker, produktägare eller kunden. Du kan också använda crowd-sourcing-plattformar för att söka efter testare eller hyra en frilansande användartestspecialist.

överväg att skapa ett socialt mediemeddelande eller till och med en målsida för att locka en publik. Dina potentiella testare bör inte nödvändigtvis vara tekniskt kunniga eller bekanta med programvarutestprocesser. De som redan har eller kommer att använda din produkt (eller kanske en liknande) kommer dock att vara bra kandidater för din UAT eftersom du i så fall kan undvika djup onboarding och QA-team involvering.

implementera testverktyg för slutanvändare och inbyggda testare

naturligtvis finns det specifika instrument på marknaden som är utformade för slutanvändartestning. De mest populära verktygen erbjuder testhanteringsfunktioner som rapportering, uppgiftsöversikter och testdokumentationsmallar. Här är några exempel på programvara som kan användas för att stödja dina UAT-aktiviteter.

Usersnap är en populär plattform för att ge visuell feedback på den testade programvaran och webbaserade applikationer. I grund och botten är det ett verktyg som låter användare markera buggarna direkt på skärmen, lämna kommentarer och förslag och dela feedbacken. Det finns många liknande instrument som Userback och UserTesting.

FitNesse är en öppen källkod, wiki-driven ram för acceptanstestautomatisering. Det gör att alla intressenter enkelt kan skapa, redigera och köra tester och skapa tidig feedback. Användare anger speciellt formaterade ingångar för att automatiskt generera test som omedelbart körs av systemet. Sedan returneras utmatningen och markeras beroende på om den matchar det förväntade resultatet eller inte. Denna samarbetsplattform har en mild inlärningskurva och är populär bland agila team.

Bugwolf är ett annat instrument för att leda UAT. Förutom att testa miljö och felrapportering, erbjuder det spelifiering och konkurrens funktioner för att motivera och engagera användare. Du hittar också användbara inbyggda betalningsalternativ om du ska utföra slutanvändartestning online.

välkända projekthanteringsverktyg som Jira eller Trello har också funktionalitet för att utföra UAT.

spira dashboard

Testing dashboard i SpiraTest

skapa användaracceptmiljö och kör träning

för att få ut det mesta av slutanvändartestning, börja med träningen. Dina testare och UAT-chef ansvarar för det. Överväg att strukturera din träningsprocess för att inkludera följande aspekter.

  • introducera användare till testprocessen och dess mål.
  • träna användare att använda verktyg för slutanvändartestning om du ska använda dem.
  • förse dem med rapporteringsstandarder och riktlinjer.
  • se till att användarna förstår testfall korrekt och ger stöd om det behövs.
  • förse dem med tillgång till testmiljön.

oftast kan slutanvändartestning göras på användarens sida, vilket innebär att du inte behöver förse dina testare med hårdvaran. Hela processen kan också göras online. Mer komplicerade projekt eller konfidentiella data kan kräva att du samlar in ett dedikerat team av användartestare på ditt kontor. Det är också viktigt att utse en chef som ska tillhandahålla dokumentation, verktyg och support.

kör testerna

när du har dina testscenarier och testfall är du bra att gå med testerna. För att stödja dina slutanvändare under processen och få de nödvändiga resultaten, leverera en tydlig förståelse för vilka åtgärder varje testfall kräver. Tänk på att dina användare inte är professionella testare. Under testet, se till att ge verkliga eller nära verkliga data till användarna, undvika prov innehåll eller dummy knappar. Varje missuppfattning kan få dem att fastna i testfallet.

en annan viktig aspekt är att ha dina Utvecklare redo att fixa allt som går fel. Din testmiljö kan stängas av eller det kan finnas fel som hindrar användare från att testa. Användare bör kunna komma åt nödvändig funktionalitet i varje teststadium, oavsett om det är en interaktiv design eller en funktionell app, så att de kan utföra varje testfall som ingår i testplanen.

samla utdatainformation och analysera den

under dina UAT-aktiviteter får du massor av data från testarna. Ditt QA-team måste analysera det. Uppgifterna samlas in via användarrapporter som skickas manuellt eller via ett specifikt verktyg. Dessutom kan du genomföra intervjuer med separata användare för att få mer insikt om de testfall de utförde och vad de tycker om dem.

för att utvärdera systemberedskap, överväg att mäta procentandelen tester som passerat / misslyckats / fixat.

panaya dashboard

testspårningsdashboard i Panaya

det finns också några fler punkter som bör beaktas:

systemstabilitet. Stabilitet kan bestämmas av antalet oväntade fel som uppnåtts under UAT.

täckning av testning. Täckning mäts av antalet testscenarier / fall skrivna och deras förhållande till de totala färdiga testerna. Du kan också matcha dina UAT-testresultat med användarresekartan för att förstå vilken del av funktionaliteten som lämnades otestad.

systemets användbarhet. Detta kan beräknas med antalet tester som inte passerat eftersom användaren inte hittade ett sätt att göra det. Men den övergripande UX testas under användbarhetstestning, som utförs som en separat aktivitet.

avtal/krav efterlevnad. Kravet på överensstämmelse kontrolleras efter att alla slutanvändartester är färdiga. Det säkerställer att programvarubyggnaden fortfarande motsvarar de ursprungliga kraven/kontraktets omfattning, även efter ändringar som orsakats av användarens acceptans.

fixa fel, testa igen och logga ut

efter att ha kört UAT måste alla fel dokumenteras med relevanta kommentarer och skickas till utvecklingsteamet. De måste göra justeringar av koden för att ta itu med de problem som avslöjats av UAT.

när du fixar buggarna, testa dem igen för att se till att allt fungerar korrekt. När acceptanskriterierna uppnås och godkänns av granskare fattas det slutliga acceptansbeslutet om produktens produktionsberedskap.

UAT-teamroller

som vi nämnde tidigare skiljer sig UAT-testning från andra QA-aktiviteter eftersom det inte bara utförs av tekniska specialister; det är också viktigt att engagera faktiska slutanvändare i denna process. Att involvera QA-proffs och affärsanalytiker är också nödvändigt, liksom ett nära samarbete med projektledaren och utvecklingsteamet.

UAT-teamets ansvar kan variera beroende på företagets och projektets behov, men här är ett exempel på rollfördelningen du kan överväga.

Business Program manager. Det här är personen som samordnar och övervakar hela projektet och anpassar det till affärsmål. Innan UAT-scenen ska programchefen generera programleveransplanen och dokument för affärskrav för att stödja testaktiviteterna. Han / hon ansvarar också för att granska och godkänna testplanen och teststrategin.

under UAT övervakar programhanteraren utförandet av testaktiviteter och säkerställer slutförande enligt schema och budget. Därefter granskar han / hon testrapporten och beslutar om distribution till produktion.

UAT testledning / chef. Testledarens ansvar är att noggrant planera och organisera UAT. För det krävs vanligtvis ett nära samarbete med projektledaren.

testledaren samlar och analyserar alla affärs-och funktionskrav som sedan används för att utveckla nödvändig dokumentation, dvs teststrategi, testplan, testscenarier etc. Dessutom arbetar han/hon i förberedelsesteget med testteamet, tilldelar testscenarier till teammedlemmar och organiserar utbildning för att se till att testare förstår UAT-proceduren. Testledningen förbereder och hanterar också nödvändiga resurser och laddar viktiga testdata i testverktyg.

i hela UAT samordnar ledningen utförandet av testfall och ser till att alla testresultat dokumenteras. Han / hon spårar också testframsteg, samlar in mätvärden och skapar/underhåller en testrapport.

UAT test teammedlemmar. Testgruppens huvuduppgift är att utföra tester i enlighet med det angivna schemat och instruktionerna. Testare bör skapa testloggar och rapportera om defekter och incidenter. De deltar också vanligtvis i omtestningsaktiviteter (om det behövs).

projektledaren, som ansvarig för framgångsrikt slutförande av projektet, måste övervaka testaktiviteter, ge organisatoriskt stöd och rapportera om framsteg. Han / hon skulle också fungera som medlare mellan testteamet, Utvecklare, kund och andra möjliga intressenter.

UAT checklista

Sammanfattningsvis UAT riktlinjer vi presenterade ovan, Vi har utvecklat en checklista för att hjälpa dig att organisera dina testaktiviteter och inte miste om något viktigt.

initiera UAT-projektet.

  1. Kontrollera med ditt utvecklingsteam att alla produktkomponenter är klara för testning. Dokumentera eventuella problem som inte kunde åtgärdas före UAT.
  2. identifiera de viktigaste intressenterna.
  3. välj en teamledare som ansvarar för projektet, inklusive pappersarbete.
  4. diskutera och komma överens om projektstrukturen, UAT-teamet och UAT-dokumentationen.
  5. diskutera noggrant testprocedurerna och skapa en initial UAT-plan.

planering UAT.

  1. skapa ditt UAT-team och se till att du har testare från varje marknadssegment och/eller varje grupp av intressenter. Var säker på att all deltagarrelaterad dokumentation är fullständig och undertecknad (icke-avslöjande, deltagaravtal etc.).
  2. kommunicera teststrategin och schemat till teamet. Se till att varje medlem förstår Roller, förfaranden, och ansvar.
  3. se till att alla affärskrav fångas och kommuniceras till UAT-teamet.
  4. diskutera och komma överens om in-och utresekriterier.
  5. Förbered all affärsdokumentation: testplan, testscenarier,testfall etc.
  6. kommunicera affärsmålen och acceptanskriterierna för systemet.
  7. enas om rapporteringsstandarder.
  8. utför den nödvändiga träningen på systemet och hjälpverktygen. Se till att testarna förstår hur man rapporterar incidenter.
  9. samla och förbereda alla nödvändiga resurser för UAT-aktiviteter. Boka utrymme om det behövs.
  10. Förbered och testa miljön, testhanteringsverktyg, enheter, servrar, feedbackkanaler, ärendespårning, innehållsleverans etc.
  11. kontrollera att du har alla inloggningar, att säkerhetsåtkomst har ställts in och testdata har laddats.

exekvera UAT.

  1. övervaka hur procedurer utförs och se till att rapporter lämnas in i rätt tid och korrekt.
  2. skapa och underhålla testsammanfattningsrapporten.

Post – UAT aktiviteter.

  1. analysera utdatainformationen genom att mäta procentandelen tester som passerade/misslyckades samt kategorisera defekter efter svårighetsgrad.
  2. identifiera status mot acceptanskriterier.
  3. Förbered den slutliga UAT-rapporten och presentera den för intressenter tillsammans med beräknad tid och ansträngning som krävs för att uppfylla acceptkriterier och rekommendationer för release.

testprocedurer kan skilja sig från företag till företag. Här är ett par andra nedladdningsbara UAT-checklistor som också passar dina behov: checklista 1, checklista 2.

Lämna ett svar

Din e-postadress kommer inte publiceras.