Hva er Brukeren Historie og akseptkriterier (Eksempler)

En Perfekt Guide til Brukeren Historien Kriterier for Godkjenning med virkelige scenarier:

I Utvikling av Programvare-bransjen, ordet ‘Krav’ definerer hva som er målet vårt, hva kundene akkurat trenger og hva du vil gjøre vårt selskap til å øke sin virksomhet.

enten det er et produkt selskap som gjør programvare produkter eller service selskap som tilbyr tjenester i ulike programvare-felt, prime base for dem alle er kravet og suksess er definert av hvor godt kravene er oppfylt.,

begrepet «krav» har forskjellige navn i forskjellige prosjekt metodikk.

I Fossen, det er referert til som ‘Krav/Spesifikasjon Dokument’, i Smidig eller SCRUM er det referert til som ‘Episk’, ‘User Story’.

Under Fossen modell, Kravet dokumenter er store dokumenter på 200 eller flere sider som hele produktet er implementert i en fase. Men dette er ikke tilfelle med Agile/SCRUM fordi i disse metoder kravene er gitt for små funksjoner eller funksjoner som produktet er forberedt på en trinnvis måte.,

I denne artikkelen, jeg har prøvd mitt beste for å dele alle mine 4 år med erfaring på å arbeide med Brukeren historier og tilhørende akseptkriterier sammen med lett og enkel virkelige scenarier for bedre forståelse.

La oss besøk det grunnleggende først.

Hva er en Bruker Historien?

En user story er et krav for enhver funksjonalitet eller funksjon som er skrevet ned i en eller to linjer, og maks opp til 5 linjer. En bruker historien er vanligvis den enkleste mulige krav og er om lag ett og bare ett-funksjonalitet (eller en funksjon).,

Den mest brukte standard-formatet for en Bruker Historien etableringen er angitt nedenfor:

Som en <brukerens rolle/customer, Jeg ønsker å < målet skal nås> slik at jeg kan <grunn av mål>.

Eksempel:

Som en WhatsApp brukeren, jeg ønsker et kamera-ikonet i chat-boksen skriver til å ta og sende bilder slik at jeg kan klikke og dele mine bilder samtidig med alle mine venner.

Hva er en Aksept Kriterier?,

En aksept kriteriet er et sett av godkjente betingelser eller bedrift regler som funksjonaliteten eller funksjonene bør tilfredsstille og møte, for å bli akseptert av det Produktet Eier/Interessenter.

Dette er en svært viktig del av brukeren historien ferdigstillelse, og det bør bli studert ved Produktet Eier og Virksomhet Analytiker svært omhyggelig fordi det mangler et enkelt kriterium som kan koste mye. Dette er en enkel nummerert eller punktmerket liste.

Sine formatet er som følger:

«Gitt noen forutsetning når jeg gjør noen handling, så jeg forventer resultatet».

Eksempel (b.r.,t ovenfor brukeren historie):

• La oss tenke på at jeg chatter med en venn, og jeg burde være i stand til å ta et bilde.
• Når jeg klikker på et bilde, bør jeg være i stand til å legge til en bildetekst for bildet før du sender den.
• Hvis det er noen problem med å starte telefonen min kameraet, vises det en feilmelding som » Kameraet kan ikke være i gang. osv. bør være vist tilsvarende.

Derfor, Brukeren historien definerer kravet for enhver funksjonalitet eller funksjon er tilgjengelig, mens Aksept Kriterier definerer ‘Definisjon av» ferdig » for brukeren historie eller krav.,

Som et QA-det er veldig viktig å forstå brukeren historie og dets kriterier for aksept dypt med ikke en eneste tvil om igjen på ‘start av testing. Fremover la oss forstå hvorfor det er svært viktig å grave ‘dype’ i bruker historier og kriterier for aksept.

Grave dypt inn i User stories

til Å begynne med, la oss først forstå betydningen av en «in-depth’ studie av en grunnleggende og fundamentale ting dvs. Brukeren Historier.

følgende tilfeller er mine egne reelle erfaringer.,

Case #1:

Før 3 år, jobbet jeg på en Mobil Applikasjon Prosjektet og produktet var et program som var utformet for levering folk.

Du ville ha sett en leveranse person som kommer til ditt sted for levering. Og de har en mobiltelefon som de be deg om å gi din signatur etter levering. Denne signaturen gjenspeiler på portal of the courier tjenesteleverandører som DTDC, FedEx, etc.

La oss tenke oss at appen er nettopp lansert, og deres portaler er allerede eksisterende og opp.,

Problemet: For en Sprint Produktet eier har en bruker historien for dette mobil-app som «Som en Portal Admin, bør jeg være i stand til å vise signatur tatt ved levering person ved levering». Her portalen (web app) er endret og oppdatert i henhold til dette for å gjenspeile signatur.

Som en QA du har for å kontrollere om signaturen fanget i det mobile app er noe som gjenspeiler seg som forventet i portalen.,

Hvis du ser på denne brukeren historien, det ser enkelt, men det er en skjult forutsetning her at «For historiske leveranser, var det ingen signatur refleksjon funksjonalitet, så hva skal skje hvis portalen gutta vise historiske leveranser?»Bør historiske data bli utryddet? Bør vi tillate krasjer eller feil for slike data?

selvfølgelig ikke i det hele tatt, dette skal håndteres allernådigst.,

Løsning: Når de respektive DB tabeller er oppdatert for å legge til en ny kolonne for Signatur sted, den gamle data bør ha en NULL eller 0-verdi som skal kontrolleres og en melding som sier ‘Ingen signatur eksisterer» skal bli vist.

Dette kan kalles som en glipp fra produkteier eller Business Analyst, men dette må gjøres. Å implementere en funksjon hell, men å bryte noe med det er ikke ønskelig av kundene. Dette må gjøres sammen med den samme brukeren historien og i samme sprint.,

Case #2

6 år siden, jobbet jeg på en Pensjonisttilværelse Planlegging Finance-Program (med ingen BA) som var et globalt program der Finans folk som CA, Finance-Rådgivere kan bruke det for forskjellige valutaer til prosjektet investeringsplaner, sparepenger, etc. over en stor periode til sine kunder.

Problemet: produkteier gir du en Bruker Historien som «Som en Rådgiver, ønsker jeg å vise rapporten av kundene mine er basert på finansielle opplysninger gitt».,

Her var det 2 skjult krav og jeg vil kalle det som en ufullstendig historie fordi:

a] rapportene bør vurdere den daglige valuta pris og ikke den historiske som i siste sett rapport og

b] Hvis valuta er endret, etter å ha kundens finansielle detaljer, rapportene skal vise i endret valuta.

Løsning: jeg har oppdratt 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 kommende sprint med prioritet.,

Ta Unna: Disse ble fanget fordi vi alle var veldig godt klar av produkter, deres design, struktur osv. Slik kunnskap kan kun oppnåes ved forståelse produktet helt, ved å forstå interoperabilitet av moduler og ved å studere brukeren historien grundig selv om det er en 2 liner.

Ta notater for å gjøre ting enklere og diskutere med BA ‘ s og utviklere om sin tenkning.,

I Dybden og se på Kriterier for Aksept

Forstå kriterier for aksept og alle de andre forholdene& uttømmende regler er enda mer viktig enn forståelse en bruker historien. Fordi dersom kravet er ufullstendig eller uklar, det kan bli tatt opp i neste sprint, men hvis en aksept kriteriet er savnet, så brukeren historien i seg selv kan ikke bli utgitt.

jeg tror vi alle ville ha brukt nettbank på et tidspunkt, og de fleste av oss bruker den hver dag, og jeg ned mine historiske uttalelser mye., Hvis du observerer den nøye, det er visse spesifikke alternativer som er tilgjengelige for å laste dem ned.

Det er et alternativ for å velge type fil for å laste ned kontoutskriften. Det er et alternativ for å velge om du vil laste ned kun Kreditt/Debit – /begge.

tenk deg at Produktet Eier gir deg denne Brukeren historie «Som en kunde, jeg ønsker å laste ned kontoen min uttalelse, slik at jeg kan vise alle mine transaksjoner som er gjort for en spesifikk periode».,

Med følgende Kriterier for Godkjenning:

• tatt i Betraktning at jeg er på Last ned-Historisk Erklæring Side, jeg bør velge den perioden som jeg ønsker å laste ned uttalelsen.
• tatt i Betraktning at jeg er på Last ned-Historisk Erklæring Side, jeg skulle velge kontoen som jeg ønsker å laste ned uttalelsen.
• tatt i Betraktning at jeg er på Last ned-Historisk Erklæring Side, jeg skal ikke være lov å laste ned uttalelse for fremtiden » Til » dato.,
• tatt i Betraktning at jeg er på Last ned-Historisk Erklæring Side, jeg skulle ikke få lov til å velge » Fra » dato 10 år utover i det siste.
• tatt i Betraktning at jeg ned min uttalelse, bør jeg være i stand til å vise den nedlastede filen.
• tatt i Betraktning at jeg er på Last ned-Historisk Erklæring Side, bør jeg være i stand til å laste ned min uttalelse i doc, excel-og pdf-formater.

Hvis du går gjennom denne aksepten, det er 3 ting som mangler her:

• Navn og format på fil som skal lastes ned.,
• Hva slags informasjon (kolonnenavn) skal vises i filen.
• alternativer-listen for å velge hvilken type transaksjon det kunden ønsker dvs. bare belastninger eller bare studiepoeng eller begge deler.

Slike tilfeller kan skje en gang i en stund, men fortsatt studie godt om hver kriterier for aksept og prøver å visualisere det med referanse til brukeren historie. Jo mer du studerer dypt om forholdene og virksomheten reglene jo mer vil være din kunnskap om den funksjonen.

Feil funnet i den innledende fasen koster ingenting i forhold til hva det kan koste i ‘testing’ – scenen.,

Viktigheten av å finne Avvik i User Story/Kriterier for Aksept

Det er alltid viktig å gjøre et dypdykk i de bruker historier og kriterier for aksept på et tidlig stadium før den utvikling eller testing starter.

Fordi det innebærer:

#1) Sløseri av Tid:

Hvis avvik eller feil i user story/akseptkriterier er funnet når utviklingen kommer på eller testing er å gå på, så mye etterarbeid må kanskje gjøres i de resterende sprint tid.,

Det skjer ikke på at selv om Produktet Eier glipp av noen ting, de vil flytte brukeren historien til den kommende sprint. 95% sjansene er at de spør teamet til å gjøre de nødvendige gjennomføring og slipp det i samme sprint.

Derfor blir det et mareritt for laget som de har til å tilbringe ekstra tid, kommer i helger eller på jobb sent på kvelden. Dette kan unngås ved å studere og diskutere user story/kriterier for aksept på et tidligst mulig stadium.

#2) Svinn av Innsats:

utviklere og QA ha tilbake den implementert kode og test sakene igjen., Oppdatere, legge til og fjerne som per kravet er ikke en lett oppgave. Det blir for smertefullt som det er allerede et press for å levere på tid.

I en slik situasjon, det er sjanser for feil i utvikling eller testing scenen. Hvis du kommer over en slik situasjon går for ‘DevQA Sammenkobling’. Som en glasur på kaken, kan du ikke få en kompensasjon for den ekstra arbeid.

Konklusjon

Dyp forståelse av Brukeren Historie og kriterier for godkjenning kan bare oppnås ved å bruke enormt med tid på å studere den.,

Det er ingen spesielle verktøy eller kurs som er tilgjengelig i markedet for å gjøre dette for deg, da dette handler om logisk tenkning, opplevelse og kunnskap om produktet.

Delta i Pre-planen møte aktivt, snakker til BA, å studere på egen hånd kan bare hjelpe deg til å oppnå dette. Jo mer innsats du legger, jo mer vil du lære og vokse.

Skal det QA ‘ s eller utviklere, alle har til å være på samme side om brukeren historier og deres kriterier for aksept, bare så forventningene til kunden kan oppnås vellykket.,

har du noe nytt å dele med oss om dine opplevelser og erfaringer i arbeidet med Brukeren Historier? Vennligst uttrykke dine tanker nedenfor!!