Hvad er brugerhistorie og acceptkriterier (eksempler)

Eksempel:

Som WhatsApp-bruger vil jeg have et kameraikon i chatfeltboksen til at tage og sende billeder, så jeg kan klikke og dele mine billeder samtidigt med alle mine venner.

Hvad er acceptkriterier?

Et acceptkriterium er et sæt af accepterede betingelser eller forretningsregler, som funktionaliteten eller funktionen skal opfylde og opfylde for at blive accepteret af Produktejeren / Interessenterne.

Dette er en meget vigtig del af færdiggørelsen af ​​brugerhistorien, og den bør undersøges af produktejeren og forretningsanalytikeren meget omhyggeligt, fordi manglende et enkelt kriterium kan koste meget. Dette er en simpel nummereret eller punktopstillet liste.

Dens format er som følger:

' Givet en forudsætning, når jeg foretager mig noget, forventer jeg resultatet ”.

konvertere tegn til streng c ++

Eksempel (w.r.t til ovenstående brugerhistorie):

• Lad os overveje, at jeg chatter med en ven, og at jeg skal være i stand til at tage et billede.
• Når jeg klikker på et billede, skal jeg kunne tilføje billedtekst til billedet, før jeg sender det.
• Hvis der er noget problem med at starte mit telefonkamera, kunne en fejlmeddelelse som 'Kamera ikke kunne startes'. osv., skal vises i overensstemmelse hermed.

Derfor definerer brugerhistorien kravet til enhver funktionalitet eller funktion, mens acceptkriterierne definerer 'Definition af færdig' for brugerhistorien eller kravet.

Som en kvalitetssikring er det meget vigtigt at forstå brugerhistorien og dens acceptkriterier dybt, med ikke engang en tvivl tilbage ved teststart. Lad os forstå, hvorfor det er ekstremt vigtigt at grave 'dybt' i brugerhistorier og acceptkriterier.

Graver dybt ned i brugerhistorier

Til at begynde med skal vi først forstå vigtigheden af ​​en 'dybtgående' undersøgelse af en grundlæggende og grundlæggende ting, dvs. Brugerhistorier.

Følgende tilfælde er mine egne virkelige oplevelser.

Sag nr. 1:

Før 3 år arbejdede jeg på et mobilapplikationsprojekt, og produktet var en applikation, der var designet til leveringsfolkene.

Du ville have set en leveringsperson komme til dit sted for levering. Og de har en mobiltelefon, som de beder dig om at give din underskrift efter levering. Denne signatur afspejler portalen til kurertjenesteudbydere som DTDC, FedEx osv.

Lad os forestille os, at mobilappen lige er lanceret, og at deres portaler allerede er eksisterende og op.

Problem: For en sprint har din produktejer en brugerhistorie til denne mobilapp, der “Som portaladministrator skal jeg kunne se signaturen, som leveringspersonen har taget på leveringstidspunktet” . Her ændres portalen (webapp) og opdateres i overensstemmelse hermed for at afspejle signaturen.

Som en kvalitetssikring skal du kontrollere, om signaturen, der er fanget i mobilappen, afspejler som forventet i portalen.

Hvis du ser på denne brugerhistorie, ser det simpelt ud, men der er et skjult krav her, at 'For historiske leverancer var der ingen signaturrefleksionsfunktionalitet, så hvad skal der ske, hvis portalens fyre ser historiske leverancer?' Bør historiske data udslettes? Bør vi tillade nedbrud eller fejl for sådanne data?

Naturligvis slet ikke, dette skal håndteres nådigt.

Opløsning: Når de respektive DB-tabeller opdateres for at tilføje en ny kolonne til signaturplaceringen, skal de gamle data have en NULL- eller 0-værdi, som skal kontrolleres, og en meddelelse om, at der ikke findes nogen signatur, skal vises.

Dette kan kaldes som en miss fra produktejeren eller forretningsanalytikeren, men dette skal gøres. Implementering af en funktion med succes, men at bryde noget sammen med det er ikke ønskeligt af kunderne. Dette skal gøres sammen med den samme brugerhistorie og i samme sprint.

Sag nr. 2

For 6 år siden arbejdede jeg på en finansieringsapplikation til pensionering (uden BA), som var en global applikation, hvor finansfolk som CA, finansrådgivere kunne bruge det til forskellige valutaer til at projicere investeringsplaner, besparelser osv. Over en periode lang periode til deres kunder.

Problem: Produktejeren giver dig en brugerhistorie, der “Som rådgiver vil jeg se rapporten fra min kunde baseret på de økonomiske oplysninger, der er givet”.

Her var der 2 skjulte krav, og jeg vil kalde det som en ufuldstændig historie, fordi:

til) Rapporterne skal overveje den daglige valutakonverteringskurs og ikke den historiske som i den sidst viste rapport og

b) Hvis valutaen ændres efter at have givet kundens økonomiske oplysninger, skal rapporterne vises i den ændrede valuta.

Opløsning: Jeg rejste denne bekymring direkte med vores produktejer og gjorde ham opmærksom på, at begge disse skulle gøres så hurtigt som muligt. Han var enig med mig og skabte 2 forskellige historier til de kommende sprints med prioritet.

Tag væk: Disse blev fanget, fordi vi alle var meget opmærksomme på produkterne, deres design, struktur osv. Sådan viden kan kun opnås ved at forstå produktet fuldstændigt, ved at forstå modulernes interoperabilitet og ved at studere brugerhistorien grundigt, selvom det er en 2 liner.

Lav notater for at gøre tingene lettere og diskuter med BA'erne og udviklerne om deres tænkning.

Dybtgående kig på acceptkriterier

At forstå acceptancekriterierne og alle de andre betingelser og regler udtømmende er endnu vigtigere end at undervurdere en brugerhistorie. For hvis et krav er ufuldstændigt eller vagt, kan det tages op i næste sprint, men hvis et acceptkriterium savnes, kan brugerhistorien i sig selv ikke frigives.

Jeg antager, at vi alle ville have brugt netbank på et tidspunkt, og de fleste af os bruger det hver dag, og jeg downloader mine historiske udsagn meget. Hvis du observerer det nøje, er der visse specifikke muligheder for download af dem.

Der er en mulighed for at vælge filtypen til download af din erklæring. Der er en mulighed for at vælge, om du kun vil downloade kredit / debet / begge dele.

Forestil dig nu, at produktejeren giver dig denne brugerhistorie 'Som kunde vil jeg downloade min kontoudtog, så jeg kan se alle mine transaktioner udført i en bestemt periode'.

Med følgende acceptkriterier:

• I betragtning af at jeg er på siden Download historisk erklæring, skal jeg vælge den periode, som jeg vil downloade erklæringen for.
• I betragtning af at jeg er på siden Download historisk erklæring, skal jeg vælge den konto, som jeg vil downloade erklæringen for.
• I betragtning af at jeg er på siden Download historisk erklæring, bør jeg ikke få lov til at downloade erklæringen til fremtidig 'Til'-dato.
• I betragtning af at jeg er på siden Download historisk erklæring, bør jeg ikke få lov til at vælge 'Fra' -dato 10 år senere.
• I betragtning af at jeg downloader min erklæring, skal jeg kunne se den downloadede fil.
• I betragtning af at jeg er på siden Download historisk erklæring, skulle jeg være i stand til at downloade min erklæring i doc-, excel- og pdf-formater.

Hvis du gennemgår denne accept, mangler der 3 ting her:

• Navn og format på filnavnet, der downloades.
• Hvilke oplysninger (kolonnenavne) skal vises i filen.
• Indstillingslisten for at vælge, hvilken type transaktion kunden ønsker, dvs. kun debiteringer eller kun kreditter eller begge dele.

Sådanne tilfælde kan ske en gang imellem, men studer stadig godt om hvert acceptkriterium og forsøg at visualisere det med henvisning til brugerhistorien. Jo mere du studerer dybt omkring betingelserne og forretningsreglerne, jo mere vil din viden om funktionen være.

Fejl, der blev fundet i den indledende fase, kostede intet i forhold til hvad det kan koste i 'test' -fasen.

Vigtigheden af ​​at finde uoverensstemmelser i brugerhistorie / acceptkriterier

Det er altid vigtigt at lave et dybt dyk i brugerhistorierne og acceptkriterierne på et tidligt tidspunkt, selv før udviklingen eller testningen påbegyndes.

Fordi det involverer:

# 1) Spild af tid:

Hvis der findes uoverensstemmelser eller fejl i brugerhistorien / acceptkriterierne, når udviklingen foregår eller testningen foregår, kan det være nødvendigt at foretage en masse omarbejdning i den resterende sprinttid.

Det sker ikke, at selvom Produktejeren gik glip af få ting, flyttede de brugerhistorien til den kommende sprint. 95% chancer er, at de beder holdet om at udføre den nødvendige implementering og frigive det i samme sprint.

Derfor bliver det et mareridt for holdet, da de skal bruge ekstra tid, komme i weekenden eller arbejde sent om aftenen. Dette kan undgås ved at studere og diskutere brugerhistorien / acceptkriterierne så tidligt som muligt.

# 2) Spild af indsats:

Udviklerne og QA skal revidere den implementerede kode og teste sager igen. Opdatering, tilføjelse og fjernelse som pr. Krav er ikke en let opgave. Det bliver for smertefuldt, da der allerede er et pres på at levere til tiden.

I en sådan situation er der chancer for fejl i udviklings- eller testfasen. Hvis du støder på en sådan situation, gå til 'DevQA-parring'. Som en prikken over i'et får du muligvis ikke en kompensation for det ekstra arbejde.

Konklusion

Dyb forståelse af brugerhistorie og acceptkriterier kan kun opnås ved at bruge enorm tid på at studere den.

Der er ikke noget specifikt værktøj eller kursus til rådighed på markedet til at gøre dette for dig, da det hele handler om logisk tænkning, erfaring og viden om produktet.

At deltage aktivt i Pre-plan møde, tale med BA, studere alene kan kun hjælpe dig med at opnå dette. Jo mere du bestræber dig, jo mere lærer du og vokser.

Det være sig QA'erne eller udviklerne, alle skal være på samme side om brugerhistorierne og deres acceptkriterier, kun så kan kundens forventninger opnås med succes.

Har du noget nyt at dele med os om dine erfaringer med at arbejde med brugerhistorier? Venligst udtryk dine tanker nedenfor !!

Anbefalet læsning

• MongoDB Opret bruger og tildel roller med eksempler
• Eksempelskabelon til acceptrapport med eksempler
• Brugergodkendelse i MongoDB
• JMeter-dataparameterisering ved hjælp af brugerdefinerede variabler
• Unix-tilladelser: Filtilladelser i Unix med eksempler
• Hvad er acceptstest (En komplet guide)
• Hvad er test af brugeraccept (UAT): En komplet guide
• Python DateTime-tutorial med eksempler