Lesetid: 14 minutter
for å sikre de tekniske egenskapene til et produkt, for å finne feil og logiske feil i programvaren, er det viktig å engasjere seg i kvalitetssikringsaktiviteter. QA-testing vil imidlertid ikke fortelle deg om sluttproduktet er i samsvar med forretningsmål og kan utføre nødvendige oppgaver i virkelige scenarier. Så for å sikre at utviklingsteamet bygger riktig produkt for de faktiske sluttbrukerne, er det viktig å gjennomføre brukerakseptstesting.
hva er brukerakseptstesting og hvordan skiller det seg fra kvalitetssikring?
Uat (User Acceptance Testing) kontrollerer om et produkt er det rette for sluttbrukerne. Den har andre navn, for eksempel sluttbrukertesting, operativ, applikasjon, beta-testing eller validering, men de beskriver det samme. I kvalitetssikring er det viktig å skille mellom validering og verifisering.
Verifisering refererer til generelle QA-prosesser som tar sikte på å teste de tekniske aspektene ved et produkt for å sikre at det faktisk fungerer. Validering (eller brukeraksepttesting) utføres for å sikre at produktet samsvarer med forretningsbehov og kan brukes av sluttbrukeren.
Validerings-og verifiseringsaktiviteter i form av total produkttesting
Valideringsaktivitet kan deles inn i to typer testing.
Alpha testing er den innledende fasen av aksept testing, vanligvis utført av interne testere, for å sikre at produktet fungerer riktig og oppfyller forretningskrav.
Beta testing, den andre typen aksept testing, tar sikte på å møte bruker aksept kriterier. UAT kan utføres av
- de faktiske brukerne av et eksisterende produkt,
- brukere av en tidligere versjon av et produkt,
- interessenter involvert i utviklingen av produktet, og/eller
- forretningsanalytikere som sluttbrukerspesialister.
dette gjør det mulig for utviklingsteamet å fikse de fleste bruksproblemer, feil og uventede problemer med funksjonalitet, systemdesign, forretningskrav, etc.
Hvorfor trenger du FAKTISK UAT?
hovedformålet med godkjenningstesting er å validere at produktet samsvarer med brukernes behov (definert på produktoppdagelsesstadiet) og er klart for lansering. Ifølge En Origsoft-undersøkelse om UAT-bruk, sa over 75 prosent av respondentene at de utfører flere sykluser av sluttbrukertesting med 57 prosent som hevder den dårlige kvaliteten på produktet som en grunn.
så, her er de viktigste årsakene TIL AT UAT er viktig og bør være en del av utviklingen din.
Sikre korrespondanse med forretningsbehov. SOM vi allerede nevnte, er UAT gjort for å verifisere at produktet opererer i de virkelige forholdene etter behov, og lar sluttbrukere løse målrettede problemer. Hvis DU hopper OVER UAT, kan du gå glipp av noen viktige feil eller systemfeil som uunngåelig vil føre til misnøye for brukeren.
Juster innledende krav. Noen ganger, som sluttbrukere teste produktet, kan de komme opp med noen verdifulle tanker om hvordan du kan forbedre testet programvare. Å få slike tilbakemeldinger vil tillate deg å justere dine krav for å få et resultat som vil være mer nyttig for kundene dine.
Unngå tap. For det første er det billigere å fikse produktet i de tidlige utviklingsstadiene ,så å finne feil på GRUNN AV UAT vil tillate utviklingsteamet å forbedre produktet mye lettere (det gjelder for Det meste Den Smidige modellen skjønt. Les videre for flere detaljer). For det andre vet vi alle historier om produktfeil på grunn av dårlig funksjonalitet og brukervennlighet. UAT gir deg tilbakemeldinger fra brukere i den virkelige verden og gjør det langt mindre sannsynlig at tap skyldes en mislykket produktlansering.
I ALLE fall krever UAT organisering og forberedelsesarbeid for å gjøre det effektivt. Hvis du vil sikre produktets gyldighet, bør du vurdere følgende trinn i å gjennomføre brukerakseptstesting.
uat viktige stadier
Analyser produktkrav og definer viktige leveranser
Analysere produktkrav er det første trinnet I uat planlegging. Den primære kilden til inngangsinformasjon vil være programvarekrav spesifikasjonen som det inkluderer hele omfanget av virksomheten og funksjonelle krav.
Forretningskrav Er målene på høyt nivå for organisasjonen som kommuniserer forretningsbehov. De kan høres ut som » kunder skal kunne bruke flere betalingsmåter.»
Funksjonelle krav bygger bro over en teknisk løsning med forretningskravene. Så, det funksjonelle kravet ville høres ut som «implementere PayPal, Visa Og Mastercard, Payoneer betaling gateways.»
oversikten over disse kravene vil fortelle deg nøyaktig hva du bør teste, om de implementerte løsningene fungerer for brukerne og løser problemer for virksomheten. Funksjonelle krav kan oversettes til testtilfeller, med tanke på suksesskriteriene for forretningskrav. Og det vil hjelpe deg med å danne en overordnet teststrategi. Vurder å engasjere forretningsanalytikere, QA-ingeniører eller produkteiere for kravanalyse.
det siste planleggingsstadiet er å lage teknisk dokumentasjon for uat-prosessen. Her dokumenterer du teststrategi, regler, testscenarier/saker, standarder, etc. Følgende avsnitt beskriver dokumentasjonen som brukes i brukerakseptstesting.
Levering Av brukeraksept-testing
UAT-testplan. Opprette EN uat test plan vil hjelpe deg å holde alle på linje med de samme mål og visjon. Hoveddokumentet inneholder all informasjon om hva som skal testes, av hvem og hvordan. For å dekke alle organisatoriske og prosessuelle aspekter AV UAT, må du detaljere teststrategien og inngangs – /utgangskriteriene.
Strategi For Sluttbrukertesting. Strategien skisserer produktet du tester, formålet med brukerakseptstesting, typer tester og mål. Teststrategien din bør dekke slik informasjon som
- produktbeskrivelse,
- testmål,
- testomfang,
- standarder,
- testtyper,
- testere/roller
- prosesskuratorer (ledere),
- anmeldere,
- rapporteringsstandarder og
- resultater.
Oppføringskriterier. Dette er betingelsene som fastslår at programvaren er klar til å bli testet. De er satt på det tidligste stadiet av planlegging av utviklingsteamet, QA, forretningsanalytikere og interessenter.
Kriterier For Avslutning eller aksept. Dette er betingelsene som tilsier at programvaren er gyldig for brukerne. Matchende akseptkriterier vil være den siste fasen av UAT.
Testscenarier. Testscenarier er hypotetiske situasjoner som brukere kan støte på når de samhandler med produktet. Deres mål er å veilede testere gjennom mulige systembruk problemer.
I Utgangspunktet bør et testscenario formidle en enkel ide om hva som skal testes. Et eksempel på et scenario er » sjekk handlekurv funksjonalitet.»Hvert brukerscenario er knyttet til ett eller to krav eller brukerhistorier. De er skrevet for å validere at systemet er brukbart, og kontrollerer end-to-end-operasjonene med ekte data.
for å skrive gode testscenarier for brukeraksepttesting, bør du vurdere å involvere sluttbrukere i godkjenning for å inkludere alle mulige brukstilfeller, både vanlige og uvanlige. Vurder også å skrive dem i vanlig språk, unngå kompliserte frasering eller altfor tekniske forklaringer.
Testtilfeller. Et testtilfelle er et sett med bestemte handlinger som utføres for å teste og verifisere en bestemt systematferd, funksjon eller funksjonalitet. Testtilfeller er mer detaljerte enheter som må samsvare med alle testscenarier. Oftest vil du konvertere dine brukerhistorier og forretningsbrukssaker til å skrive effektive testtilfeller. Eksempler på testtilfeller er:
- Sjekk uregistrert bruker legge produktet i handlekurven.
- Sjekk handlekurv filtrering.
- Sjekk» fortsett å handle » – knappen.
Testtilfeller er effektive når det er et klart formål oppgitt, og brukeren er i stand til å forstå hva de skal gjøre for å fullføre det. Brukerhåndboken til et testfall kan se slik ut:
- Åpne programmet.
- Legg til et produkt i en handlekurv.
- Godkjenning er ikke nødvendig.
- Fortsett til handlekurven.
du kan også inkludere forventede resultater i testen, slik at brukeren er klar over hva som skal skje:
- produktet vil vises i en handlekurv.
- systemet vil be deg om å autorisere som registrert bruker.
Rapporteringsstandarder. Definer hvordan en rapport skal se ut og hvilken informasjon en sluttbruker skal gi.
Testrapporter. Disse akkumulerer dokumenterte utgangsdata når testen er fullført. Avhengig av teststandarder og testscenario kan ulike opplysninger inkluderes i rapporter. Men vanligvis I UAT, VIL QA-lag bare kreve en sign-off fra testeren. En pålogging er bare en bekreftelse på at testen er vellykket, og den tilsvarer brukerens kriterier.
på slutten AV UAT kan leveranser som tilbys, brukes av qa-ingeniører eller EN UAT-leder for å trekke ut verdifulle data og kommunisere resultater til utviklingsteamet.
tradisjonelt vil kvalitetssikringsingeniører være ansvarlige for å behandle tilbakemeldinger fra sluttbrukere. Resultatene av tester, feilrapporter og fail / pass poster er gitt til utviklere for å sikre konstant kommunikasjon mellom ulike deler av teamet. BASERT på tilbakemeldinger fra sluttbrukere kan QA-teamet også tilby programvarekvalitetsmålinger for å måle fremgang når DET gjelder UAT.
brukeraksept testing maler
Vi har nevnt noen viktige dokumenter som må opprettes for riktig uat planlegging og gjennomføring. Det er forskjellige måter å skrive dem på, men her er noen maler som kan komme til nytte.
- testplanmaler: Testplanmal av Coley Consulting, sfsu-mal (nedlastbar lenke) eller iiba-mal (nedlastbar lenke)
- testscenario-mal
- testrapportmal
Velg tid og form for sluttbrukertesting
Godkjenningstesting kan finne sted på ulike stadier av prosjektet, avhengig av metodikken du bruker, men vanligvis utføres Den på slutten av utviklingssyklusen før utgivelsen. Som to av de mest populære prosjektledelsesmetodene i programvareutvikling Er Waterfall og Agile, vil vi se på brukerakseptstestprosessen i de to modellene.
Godkjenningstesting i Fossemodellen
for å dykke dypere inn i detaljene må vi raskt oppsummere hva En Fossemodell er. Det er en tradisjonell prosjektledelsesmetodikk basert på en trinnvis utvikling av produktet.
stadiene krysser ikke, noe som betyr at det ikke er samtidig design og designtesting, eller utvikling og testing. Hele prosessen er strengt dokumentert og ment å levere et fullt funksjonelt program på slutten av utviklingen uten gjentakelser.
brukerakseptstadium i Fossemodellen
brukerakseptprøving i Foss finner sted i sluttfasen av utviklingen, rett før lanseringen.
Det kan kun utføres etter at systemet anses som kode og funksjon klar, etter å ha oppnådd følgende referanser.
- krav Til produktvirksomhet er oppfylt.
- kodebasen er ferdig.
- QA-aktiviteter (system, integrasjon, enhetstesting) er fullført.
- Bugs avslørt UNDER qa scenen har blitt fikset.
- Mindre visuelle problemer er i et akseptabelt område.
- brukerakseptmiljø (uat-leder, verktøy for testing, testscenarier, etc.) er opprettet.
I Fossemodellen er brukerakseptstesting det endelige punktet som demonstrerer programvareberedskap. Hvis et produkt oppfyller brukerakseptkriterier, betyr det at produktet er klart for produksjon. Uat-aktiviteter, i så fall, er for å fullføre systemkontrollen, dens funksjonalitet, brukervennlighet og feil. Men det primære målet er fortsatt å sikre at produktet samsvarer med de opprinnelige kravene og sluttbrukerbehovene.
brukeraksept i Smidige metoder
Den Smidige modellen for programvareutvikling er ikke så enkel som Foss. Den er basert på å iterere hvert utviklingsstadium til produktet når den nødvendige kvaliteten og funksjonaliteten. Iterasjoner av hver fase tillater svært fleksibel utvikling og dynamisk endring i krav, Da Agile ikke fokuserer på å skape mye dokumentasjon. Og det gjør at utviklingsteamet raskt kan svare på endrede krav fra kunden.
brukerakseptstesting i Agile-modellen
bildet viser Agile produktutviklingssyklusen med iterasjoner. Du kan utføre brukerakseptstesting på hvert trinn i prosjektet for å sikre produktets gyldighet. Hovedforskjellen mellom Uat I Foss og I Agile er AT UAT utføres flere ganger (ofte innenfor hver iterasjon), og resultatene kan påvirke de opprinnelige kravene, da det gir umiddelbar tilbakemelding på hva som fungerer best.
kontrollpunktene for å starte sluttbrukertesting i Et Agile-prosjekt er
- dannede forretningskrav,
- UX/systemdokumentasjon,
- testmateriale (interaktive mock-ups, high-fidelity prototyper, demoer) og
- brukerakseptmiljø.
I Agile er UAT en integrert del av generelle testaktiviteter, så DET kan ta forskjellige former og bruke forskjellige verktøy. For eksempel kan disse være tester på funksjonelle og ikke-funksjonelle krav eller tidlig stadium testing for å validere forutsetninger gjort under planleggingsstadiet. På slutten av hver iterasjon produserer akseptstesting leveranser som brukes til å endre krav, systemarkitektur, ux-stilguider, etc.
Rekruttere brukere og danne uat team
som vi nevnte tidligere, kan testere rekrutteres fra din eksisterende brukerbase. Avhengig av prosjektspesifikasjonene, kan de være fageksperter, virkelige brukere av produktet, interessenter, forretningsanalytikere, produkteier eller kunden. Du kan også bruke crowd-sourcing plattformer for å søke etter testere eller ansette en freelance bruker-testing spesialist.
Vurder å opprette en melding på sosiale medier eller til og med en destinasjonsside for å tiltrekke seg et publikum. Dine potensielle testere bør ikke nødvendigvis være teknisk kunnskapsrike eller kjent med programvaretestingsprosesser. Men de som allerede har eller vil bruke produktet ditt (eller kanskje en lignende), vil være gode kandidater for UAT, siden du i så fall kan unngå dyp onboarding og QA-teaminvolvering.
Implementer sluttbrukertestverktøy og innebygde testere
selvfølgelig er det spesifikke instrumenter på markedet som er designet for sluttbrukertesting. De mest populære verktøyene tilbyr funksjonalitet for testadministrasjon som rapportering, oppgaveoversikt og maler for testdokumentasjon. Her er noen eksempler på programvare som kan brukes til å støtte UAT-aktivitetene dine.
Usersnap er en populær plattform for å gi visuell tilbakemelding på testet programvare og web-baserte applikasjoner. I utgangspunktet er det et verktøy som lar brukerne merke feilene rett på skjermen, legge igjen kommentarer og forslag, og dele tilbakemeldingen. Det finnes mange lignende instrumenter som Userback og UserTesting.
FitNesse Er en åpen kildekode, wiki drevet rammeverk for aksept test automatisering. Det gjør at alle interessenter enkelt kan opprette, redigere og kjøre tester, og skape tidlig tilbakemelding. Brukere angir spesielt formaterte innganger for automatisk å generere tester som umiddelbart kjøres av systemet. Deretter returneres utgangen og utheves avhengig av om den samsvarer med forventet resultat eller ikke. Denne samarbeidsplattformen har en mild læringskurve og er populær blant Agile-team.
Bugwolf er et annet instrument for å gjennomføre UAT. Foruten testing miljø og feilrapportering, tilbyr det gamification og konkurranse funksjoner for å motivere og engasjere brukere. Du vil også finne nyttige innebygde betalingsalternativer hvis du skal utføre sluttbrukertesting på nettet.
Kjente prosjektstyringsverktøy Som Jira eller Trello har også funksjonalitet for å gjennomføre UAT.
Test dashbord I SpiraTest
Opprett brukerakseptmiljø og kjør opplæring
start med treningen for å få mest mulig ut av sluttbrukertesting. Dine testere og UAT-leder er ansvarlige for det. Vurder å strukturere treningsprosessen for å inkludere følgende aspekter.
- Introduser brukere til testprosessen og dens mål.
- Tren brukere til å bruke verktøy for sluttbrukertesting hvis du skal bruke dem.
- Gi dem rapporteringsstandarder og retningslinjer.
- Sørg for at brukerne forstår testtilfeller riktig, og gir støtte om nødvendig.
- Gi dem tilgang til testmiljøet.
ofte kan sluttbrukertesting gjøres på brukerens side, noe som betyr at du ikke trenger å forsyne testerne med maskinvaren. Hele prosessen kan også gjøres online. Mer kompliserte prosjekter eller konfidensielle data kan kreve å samle et dedikert team av brukertestere på kontoret. Det er også viktig å utnevne en leder som vil gi dokumentasjon, verktøy og støtte.
Kjør testene
Når du har testscenarier og testtilfeller, er du god til å gå med testene. For å støtte sluttbrukerne under prosessen og få de nødvendige resultatene, må du gi en klar forståelse av hvilke handlinger hver testtilfelle krever. Husk at brukerne ikke er profesjonelle testere. Under testen må du sørge for å gi ekte eller nær ekte data til brukerne, unngå prøveinnhold eller dummy-knapper. Enhver misforståelse kan få dem fast i testsaken.
Et annet viktig aspekt er å ha utviklerne klare til å fikse alt som går galt. Testmiljøet ditt kan slå seg av, eller det kan være feil som hindrer brukere i å teste. Brukere skal kunne få tilgang til nødvendig funksjonalitet på hvert trinn av testing, enten det er et interaktivt design eller en funksjonell app, slik at de kan utføre hvert testtilfelle som inngår i testplanen.
Samle utdatainformasjon og analyser den
Under UAT-aktivitetene dine får du tonnevis av data fra testerne. DITT QA-team må analysere det. Dataene samles inn via brukerrapporter som sendes manuelt eller via et bestemt verktøy. I tillegg kan du gjennomføre intervjuer med separate brukere for å få mer innsikt om testtilfellene de utførte og hva de synes om dem.
for å evaluere systemberedskap, vurder å måle prosentandelen av tester bestått/mislyktes / fast.
testsporing dashbord I Panaya
Det er også noen flere punkter som bør vurderes:
systemstabilitet. Stabilitet kan bestemmes av antall uventede feil som ble møtt under UAT.
Dekning av testing. Dekningen måles ved antall testscenarier / tilfeller skrevet og deres forhold til de samlede ferdige testene. Du kan også matche UAT-testresultatene dine med brukerreisekartet for å forstå hvilken del av funksjonaliteten som ikke ble testet.
Brukervennlighet av systemet. Dette kan beregnes med antall tester som ikke er bestått fordi brukeren ikke fant en måte å gjøre det på. MEN den generelle UX er testet under brukbarhetstesting, som utføres som en egen aktivitet.
Kontrakt/krav etterlevelse. Kravoverholdelse kontrolleres etter at alle sluttbrukertestene er ferdige. Det sikrer at programvaren bygger fortsatt tilsvarer de opprinnelige krav / kontrakt omfang, selv etter endringer brakt av brukeren aksept.
Løs feil,retest og logg av
etter å ha utført UAT, må alle feilene dokumenteres med relevante kommentarer og sendes til utviklingsteamet. De må gjøre justeringer i koden for å løse problemene som er avslørt AV UAT.
når du har løst feilene, må du teste dem for å sikre at alt fungerer som det skal. Når akseptkriteriene er nådd og godkjent av korrekturlesere, fattes den endelige akseptbeslutningen om produktberedskap.
uat teamroller
SOM vi nevnte tidligere, er uat-testing forskjellig fra ANDRE QA-aktiviteter fordi DET utføres ikke bare av tekniske spesialister; det er også viktig å engasjere faktiske sluttbrukere i denne prosessen. Involvering QA fagfolk og forretningsanalytikere er også nødvendig, som er nært samarbeid med prosjektleder og utviklingsteam.
ansvaret TIL uat-teamet kan variere avhengig av firma-og prosjektbehov, men her er et eksempel på rollefordelingen du kan vurdere.
forretnings programleder. Dette er personen som koordinerer og overvåker hele prosjektet, og tilpasser det til forretningsmål. Før UAT-scenen skal programlederen generere programleveringsplanen og forretningskrav dokumentet for å støtte testaktivitetene. Han / hun er også ansvarlig for å gjennomgå og godkjenne testplanen og teststrategien.
under UAT overvåker programlederen utførelsen av testaktiviteter og sikrer fullføring på plan og budsjett. Etterpå vurderer han / hun testrapporten og bestemmer seg for distribusjon til produksjon.
UAT testleder/leder. Testlederens ansvar er å planlegge og organisere UAT nøyaktig. For det er det vanligvis nødvendig med nært samarbeid med prosjektlederen.
testledningen samler og analyserer alle forretnings – og funksjonskrav som deretter brukes til å utvikle nødvendig dokumentasjon, dvs.teststrategi, testplan, testscenarier, etc. I tillegg, på forberedelsesstadiet, jobber han/hun med testteamet, tilordner testscenarier til lagmedlemmer og organiserer opplæring for å sikre at testere forstår uat-prosedyren. Testledningen forbereder og administrerer også de nødvendige ressursene og laster viktige testdata i testverktøy.
gjennom uat koordinerer ledelsen utførelsen av testtilfeller, og sørger for at alle testresultater er dokumentert. Han / hun sporer også test fremgang, samler beregninger, og skaper / opprettholder en testrapport.
medlemmer AV uat-testteamet. Hovedoppgaven til testteamet er å utføre tester i samsvar med den angitte tidsplanen og instruksjonene. Testere skal opprette testlogger og rapportere om feil og hendelser. De deltar også vanligvis i retesting aktiviteter(om nødvendig).
prosjektlederen, som ansvarlig for vellykket prosjektgjennomføring, må overvåke testaktiviteter, gi organisatorisk støtte og rapportere om fremdrift. Han / hun vil også fungere som mellommann mellom testteamet, utviklerne, kunden og andre mulige interessenter.
uat sjekkliste
Oppsummering av uat-retningslinjene vi presenterte ovenfor, har vi utviklet en sjekkliste for å hjelpe deg med å organisere testaktivitetene dine og ikke gå glipp av noe viktig.
Initiere UAT-prosjektet.
- Kontroller med utviklingsteamet at alle produktkomponenter er klare til testing. Dokumentere eventuelle problemer som ikke kunne løses før UAT.
- Identifiser de viktigste interessentene.
- Velg en teamleder som er ansvarlig for prosjektet, inkludert papirarbeid.
- Diskuter og bli enige om prosjektstrukturen, UAT-teamet og uat-dokumentasjonen.
- Grundig diskutere testprosedyrer Og lage en første uat plan.
Planlegger UAT.
- Lag DITT uat-team og sørg for at du har testere fra hvert markedssegment og/eller hver gruppe interessenter. Vær sikker på at all deltakelsesrelatert dokumentasjon er fullstendig og signert (taushetsplikt, deltakelsesavtale osv.).
- Kommuniser teststrategien og tidsplanen til teamet. Sørg for at hvert medlem forstår roller, prosedyrer og ansvar.
- Kontroller at alle forretningskrav er fanget og kommunisert TIL uat-teamet.
- Diskuter Og bli enige om inn-og utreisekriterier.
- Forbered all forretningsdokumentasjon: testplan, testscenarier, testtilfeller, etc.
- Kommunisere forretningsmål og aksept / exit kriterier for systemet.
- Enige om rapporteringsstandarder.
- Utfør nødvendig opplæring på systemet og tilleggsverktøyene. Sørg for at testerne forstår hvordan du rapporterer hendelser.
- Samle Og forberede alle nødvendige ressurser FOR uat aktiviteter. Book plass om nødvendig.
- Forbered og test miljøet, teststyringsverktøy, enheter, servere, tilbakemeldingskanaler, problemsporing, innholdslevering, etc.
- Kontroller at du har alle påloggingene, at sikkerhetstilgangen er konfigurert, og testdata er lastet inn.
Utfører UAT.
- Overvåk hvordan prosedyrer utføres og sørg for at rapporter sendes inn til rett tid og nøyaktig.
- Opprette og vedlikeholde testsammendragsrapporten.
Post-UAT aktiviteter.
- Analyser utdatainformasjonen ved å måle prosentandelen av tester som passerte/mislyktes, samt kategorisere feil etter alvorlighetsgrad.
- Identifiser status mot akseptkriterier.
- Utarbeide den endelige uat-rapporten og presentere den for interessenter sammen med estimert tid og krefter som kreves for å oppfylle akseptkriterier og anbefalinger for utgivelse.
Testprosedyrer kan variere fra firma til firma. Her er et par andre nedlastbare uat sjekklister som kan passe dine behov også: Sjekkliste 1, Sjekkliste 2.