Meny

Hva er brukerhistorie og akseptkriterier (eksempler)

what is user story acceptance criteria

Prøv Instrumentet Vårt For Å Eliminere Problemer

En perfekt guide til kriterier for aksept av brukerhistorier med virkelige scenarier:

I programvareutviklingsindustrien definerer ordet ‘Requirement’ hva vårt mål er, hva kundene trenger og hva som får selskapet til å øke sin virksomhet.

Det være seg et produktselskap som lager programvareprodukter eller et serviceselskap som tilbyr tjenester innen forskjellige programvarefelt, den viktigste basen for dem alle er kravet og suksessen er definert av hvor godt kravene blir oppfylt.

Begrepet ‘krav’ har forskjellige navn i forskjellige prosjektmetoder.

I Foss , blir det referert til som ‘ Krav / spesifikasjonsdokument ’, I Agile eller SCRUM det blir referert til som ‘Episk’, ‘Brukerhistorie’.

Brukerhistorie og akseptkriterier

Under Waterfall-modellen er kravdokumentene enorme dokumenter på 200 eller flere sider, ettersom hele produktet er implementert i en fase. Men dette er ikke tilfelle med Agile / SCRUM fordi i disse metodene er kravene gitt for små funksjoner eller funksjoner ettersom produktet blir fremstilt trinnvis.

I denne artikkelen har jeg prøvd mitt beste for å dele alle mine 4 års erfaring med å jobbe med brukerhistorier og deres relaterte akseptkriterier sammen med enkle og enkle virkelige scenarier for bedre forståelse.

La oss besøke det grunnleggende først.

Hva du vil lære:

Hva er en brukerhistorie?

En brukerhistorie er et krav for enhver funksjonalitet eller funksjon som er skrevet ned i en eller to linjer og maksimalt opptil 5 linjer. En brukerhistorie er vanligvis det enkleste mulige kravet og handler om en og en funksjonalitet (eller en funksjon).

Det vanligste standardformatet for en brukerhistorieoppretting er angitt nedenfor:

Som en

Eksempel:

Som WhatsApp-bruker vil jeg ha et kameraikon i chat-boksen for å fange og sende bilder slik at jeg kan klikke og dele bildene mine samtidig med alle vennene mine.

Kriterium for brukerhistorie og aksept

Hva er akseptkriterier?

Et akseptkriterium er et sett med aksepterte betingelser eller forretningsregler som funksjonaliteten eller funksjonen skal tilfredsstille og oppfylle, for å bli akseptert av produkteieren / interessentene.

Dette er en veldig viktig del av ferdigstillelsen av brukerhistorien, og den bør studeres av produktseier og forretningsanalytiker veldig nøye, fordi manglende et enkelt kriterium kan koste mye. Dette er en enkel nummerert eller punktliste.

Dens format er som følger:

' Gitt en viss forutsetning når jeg gjør noe, forventer jeg resultatet ”.

hvilken i det følgende er ikke i tilstanden til systemtestingen?

Eksempel (w.r.t til brukerhistorien ovenfor):

  • La oss vurdere at jeg chatter med en venn, og at jeg burde være i stand til å ta et bilde.
  • Når jeg klikker på et bilde, bør jeg kunne legge til en bildetekst i bildet før jeg sender det.
  • Hvis det er noe problem med å starte telefonkameraet, kan en feilmelding som 'Kamera ikke kunne startes'. osv., skal vises tilsvarende.

Derfor definerer brukerhistorien kravet til funksjonalitet eller funksjoner mens akseptkriteriene definerer ‘definisjonen av gjort’ for brukerhistorien eller kravet.

Som en kvalitetssikring er det veldig viktig å forstå brukerhistorien og dens akseptkriterier dypt, med ikke engang en eneste tvil som er igjen ved teststart. La oss forstå hvorfor det er ekstremt viktig å grave 'dypt' i brukerhistorier og akseptkriterier.

Graver dypt inn i brukerhistorier

Til å begynne med, la oss først forstå viktigheten av en 'grundig' studie av en grunnleggende og grunnleggende ting, dvs. Brukerhistorier.

Følgende tilfeller er mine egne virkelige opplevelser.

Sak nr. 1:

Før tre år jobbet jeg med et mobilapplikasjonsprosjekt, og produktet var en applikasjon som var designet for leveransene.

Du ville ha sett en leveringsperson komme til ditt sted for levering. Og de har en mobiltelefon som de ber deg om å gi din signatur etter levering. Denne signaturen gjenspeiler på portalen til budtjenesteleverandører som DTDC, FedEx etc.

La oss forestille oss at mobilappen nettopp er lansert, og portalene deres allerede er eksisterende og oppe.

Problem: For en sprint har produkteieren din en brukerhistorie for denne mobilappen som “Som portaladministrator bør jeg kunne se signaturen som ble tatt av leveringspersonen på leveringstidspunktet” . Her endres og oppdateres portalen (webappen) for å gjenspeile signaturen.

Som en kvalitetssikring må du kontrollere om signaturen som er fanget i mobilappen gjenspeiler som forventet i portalen.

Hvis du ser på denne brukerhistorien, ser den enkel ut, men det er et skjult krav her at 'For historiske leveranser var det ingen funksjoner for refleksjon av signaturer, så hva skulle skje hvis portalgutta ser på historiske leveranser?' Bør historiske data utslettes? Bør vi tillate krasj eller feil for slike data?

Selvfølgelig ikke i det hele tatt, dette skal håndteres nådig.

Løsning: Når de respektive DB-tabellene oppdateres for å legge til en ny kolonne for signaturplasseringen, skal de gamle dataene ha en NULL- eller 0-verdi som skal kontrolleres, og det skal vises en melding om at det ikke er noen signatur.

Dette kan kalles som en glipp fra produkteieren eller forretningsanalytikeren, men dette må gjøres. Å implementere en funksjon vellykket, men å bryte noe sammen med den er ikke ønskelig av kundene. Dette må gjøres sammen med den samme brukerhistorien og i samme sprint.

Sak nr. 2

For 6 år siden jobbet jeg med en pensjonsplanleggingsøkonomisøknad (uten BA) som var en global applikasjon der finansfolk som CA, finansrådgivere kunne bruke den i forskjellige valutaer til å projisere investeringsplaner, besparelser osv. Over en periode stor periode til sine kunder.

Problem: Produkteieren gir deg en brukerhistorie som “Som rådgiver vil jeg se rapporten fra kunden min basert på de økonomiske opplysningene som er gitt”.

Her var det to skjulte krav, og jeg vil kalle det som en ufullstendig historie fordi:

til] Rapportene skal ta hensyn til den daglige valutakonverteringskursen og ikke den historiske som i den sist viste rapporten og

b] Hvis valutaen endres etter å ha oppgitt kundens økonomiske detaljer, skal rapportene vises i den endrede valutaen.

Løsning: Jeg reiste denne bekymringen direkte med vår produkteier og gjorde ham oppmerksom på at begge disse måtte gjøres så snart som mulig. Han var enig med meg og lagde 2 forskjellige historier for de kommende spurtene med prioritet.

Ta bort: Disse ble fanget fordi vi alle var veldig godt klar over produktene, deres design, struktur osv. Slik kunnskap kan bare oppnås ved å forstå produktet fullstendig, ved å forstå interoperabiliteten til moduler og ved å studere brukerhistorien grundig, selv om det er en 2 liner.

Lag notater for å gjøre ting lettere og diskutere med BA og utviklerne om deres tenkning.

Dybdegående titt på akseptkriterier

Å forstå akseptkriteriene og alle de andre betingelsene og reglene uttømmende er enda viktigere enn å undervurdere en brukerhistorie. For hvis et krav er ufullstendig eller uklart, kan det tas opp i neste sprint, men hvis et akseptkriterium blir savnet, kan ikke selve brukerhistorien frigjøres.

Jeg antar at vi alle hadde brukt nettbank på et tidspunkt, og de fleste av oss bruker det hver dag, og jeg laster ned mine historiske uttalelser mye. Hvis du observerer det nøye, er det visse spesifikke alternativer tilgjengelig for nedlasting.

Det er et alternativ å velge filtype for nedlasting av uttalelsen. Det er et alternativ å velge om du bare vil laste ned kreditter / debet / begge deler.

Tenk deg nå at produkteieren gir deg denne brukerhistorien 'Som kunde vil jeg laste ned kontoutskriften min slik at jeg kan se alle transaksjonene mine som er gjort i en bestemt periode'.

Med følgende akseptkriterier:

  • Med tanke på at jeg er på siden Last ned historisk uttalelse, bør jeg velge perioden jeg vil laste ned uttalelsen for.
  • Med tanke på at jeg er på siden Last ned historisk uttalelse, bør jeg velge kontoen jeg vil laste ned uttalelsen for.
  • Tatt i betraktning at jeg er på siden Last ned historisk uttalelse, bør jeg ikke få lov til å laste ned uttalelsen for fremtidig ‘Til’-dato.
  • Med tanke på at jeg er på siden Last ned historisk utsagn, bør jeg ikke få lov til å velge 'Fra' -dato 10 år utover det siste.
  • Med tanke på at jeg laster ned uttalelsen min, bør jeg kunne se den nedlastede filen.
  • Tatt i betraktning at jeg er på siden Last ned historisk uttalelse, bør jeg kunne laste ned uttalelsen min i doc-, excel- og pdf-format.

Hvis du går gjennom denne aksept, mangler det 3 ting her:

  • Navn og format på filnavnet som skal lastes ned.
  • Hvilken informasjon (kolonnenavn) som skal vises i filen.
  • Valglisten for å velge hvilken type transaksjon kunden ønsker, dvs. bare belastninger eller bare kreditter eller begge deler.

Slike tilfeller kan skje en gang i blant, men studer likevel godt om hvert akseptkriterium og prøv å visualisere det med referanse til brukerhistorien. Jo mer du studerer dypt om forholdene og forretningsreglene, jo mer vil din kunnskap om funksjonen være.

Feil som ble funnet i den innledende fasen, koster ingenting sammenlignet med hva det kan koste i testfasen.

Akseptkriterier

Viktigheten av å finne avvik i User Story / Acceptance Criteria

Det er alltid viktig å gjøre et dypdykk i brukerhistoriene og akseptkriteriene på et tidlig stadium allerede før utviklingen eller testingen begynner.

Fordi det innebærer:

# 1) Sløsing med tid:

Hvis avvikene eller feilene i brukerhistorien / akseptkriteriene blir funnet når utvikling pågår eller testing pågår, kan det hende at det må gjøres mye omarbeid i gjenværende sprinttid.

Det skjer ikke at selv om produkteieren savnet få ting, vil de flytte brukerhistorien til den kommende sprinten. 95% sjanser er at de ber teamet om å gjøre den nødvendige implementeringen og slippe den i samme sprint.

Derfor blir det et mareritt for teamet da de må bruke ekstra tid, komme i helgene eller jobbe sent på kvelden. Dette kan unngås ved å studere og diskutere brukerhistorien / akseptkriteriene så tidlig som mulig.

# 2) Sløsing med innsats:

Utviklerne og QA må revidere den implementerte koden og teste saker på nytt. Å oppdatere, legge til og fjerne etter behov er ikke en enkel oppgave. Det blir for smertefullt ettersom det allerede er et press for å levere i tide.

I en slik situasjon er det sjanser for feil i utviklings- eller testfasen. Hvis du kommer over en slik situasjon, gå til ‘DevQA Pairing’. Som en prikken over i-en får du kanskje ikke erstatning for ekstraarbeidet.

Avvik mellom brukerhistorie og akseptkriterier

Konklusjon

Dyp forståelse av brukerhistorie og akseptkriterier kan bare oppnås ved å bruke enorm tid på å studere den.

Det er ikke noe spesifikt verktøy eller kurs tilgjengelig i markedet for å gjøre dette for deg, da dette handler om logisk tenkning, erfaring og kunnskap om produktet.

Å delta på Pre-plan-møte aktivt, snakke med BA, studere alene kan bare hjelpe deg med å oppnå dette. Jo mer innsats du legger, jo mer lærer du og vokser.

Det være seg kvalitetssikringsselskapene eller utviklerne, alle må være på samme side om brukerhistoriene og deres akseptkriterier, bare da kan forventningene til kunden lykkes.

Har du noe nytt å dele med oss ​​om dine erfaringer med å jobbe med brukerhistorier? Vennligst uttrykk tankene dine nedenfor !!

Anbefalt lesing

^