En Perfekt Guide til Bruger Historien Accept Kriterier med real-life scenarier:
I Software-industrien, ordet “Krav”, som definerer, hvad vores mål er, hvad kunderne præcis har brug for, og hvad der vil gøre vores virksomhed til at øge sin forretning.det være sig et produktfirma, der fremstiller soft .areprodukter eller et servicefirma, der tilbyder tjenester inden for forskellige soft .arefelter, den primære base for dem alle er kravet, og succesen defineres af, hvor godt kravene er opfyldt.,
udtrykket ‘krav’ har forskellige navne i forskellige projektmetoder.
i vandfald kaldes det ‘krav/Specifikationsdokument’, i Agile eller SCRUM kaldes det ‘Epic’, ‘User Story’.
Under vandfaldsmodel er Kravsdokumenterne enorme dokumenter på 200 eller flere sider, da hele produktet implementeres i en fase. Men dette er ikke tilfældet med Agile/SCRUM, fordi der i disse metoder stilles krav til små funktionaliteter eller funktioner, da produktet fremstilles trin for trin.,
i denne artikel har jeg forsøgt mit bedste for at dele alle mine 4 års erfaring med at arbejde med brugerhistorier og deres relaterede acceptkriterier sammen med lette og enkle virkelige scenarier for din bedre forståelse.
lad os igen besøge de grundlæggende elementer først.
Hvad er en brugerhistorie?
en brugerhistorie er et krav til enhver funktionalitet eller funktion, der er skrevet ned i en eller to linjer og maks.op til 5 linjer. En brugerhistorie er normalt det enklest mulige krav og handler om en og kun en funktionalitet (eller en funktion).,
Den mest almindeligt anvendte standard format for en Bruger Historien skabelse er angivet nedenfor:
<bruger rolle/kunde, Jeg ønsker at < mål, der skal opnås>, så jeg kan <grund af de mål>.eksempel:
som userhatsapp-bruger vil jeg have et kameraikon i chatskriveboksen for at fange og sende billeder, så jeg kan klikke og dele mine billeder samtidigt med alle mine venner.
Hvad er en accept kriterier?,
et acceptkriterium er et sæt 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 studeres af produktejeren og forretningsanalytikeren meget omhyggeligt, fordi manglende et enkelt kriterium kan koste meget. Dette er en simpel nummereret eller punktliste.
dens format er som følger:
“givet en forudsætning, når jeg gør noget, forventer jeg resultatet”.
eksempel (w.r.,t til ovenstående brugerhistorie):
- lad os overveje, at jeg chatter med en ven, og jeg burde kunne fange et billede.
- når jeg klikker på et billede, skal jeg kunne tilføje en billedtekst til billedet, før jeg sender det.
- hvis der er noget problem med at starte mit telefonkamera, kunne en fejlmeddelelse som ‘kamera ikke startes’. osv., skal vises i overensstemmelse hermed.derfor definerer Brugerhistorien kravet til enhver funktionalitet eller funktion, mens Acceptkriterierne definerer ‘Definition af udført’ for brugerhistorien eller kravet.,
som en QA er det meget vigtigt at forstå brugerhistorien og dens acceptkriterier dybt, uden at engang en eneste tvivl er tilbage ved ‘teststart’. Fremadrettet lad os forstå, hvorfor det er ekstremt vigtigt at grave ‘dybt’ i brugerhistorier og acceptkriterier.
grave dybt ind i brugerhistorier
lad os først forstå vigtigheden af en ‘dybdegående’ undersøgelse af en grundlæggende og grundlæggende ting, dvs.brugerhistorier.følgende tilfælde er mine egne virkelige oplevelser.,
sag #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 levering person, der kommer 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 for kurertjenesteudbydere som DTDC, fede.osv.
lad os forestille os, at mobilappen netop er lanceret, og deres portaler allerede findes og op.,
Problem: for en Sprint har din produktejer en brugerhistorie til denne mobilapp, at “som Portaladministrator skal jeg være i stand til at se den underskrift, som leveringspersonen har taget på leveringstidspunktet”. Her ændres portalen (webebapp) og opdateres i overensstemmelse hermed for at afspejle signaturen.
som en QA skal du kontrollere, om signaturen, der er optaget i mobilappen, afspejler som forventet i portalen.,
Hvis du ser på denne brugerhistorie, ser den enkel ud, men der er et skjult krav her, at “for historiske leverancer var der ingen signaturreflektionsfunktionalitet, så hvad skal der ske, hvis portalen fyre ser historiske leverancer?”Skal Historiske data udslettes? Skal vi tillade nedbrud eller fejl for sådanne data?
selvfølgelig slet ikke, dette skal håndteres elskværdigt.,
Løsning: Når de respektive DB tabeller er opdateret for at tilføje en ny kolonne til Underskrift placering, de gamle data skal have en NULL eller 0-værdi, som skal kontrolleres, og en meddelelse, der siger “Nej underskrift eksisterer’, der 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 den samme sprint.,
sag #2
6 år siden arbejdede jeg på en Pensionsplanlægningsfinansieringsapplikation (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 stor periode til deres kunder.
Problem: produktejeren giver dig en brugerhistorie, som “som rådgiver vil jeg se rapporten fra min kunde baseret på de leverede økonomiske detaljer”.,
Her var der 2 skjulte krav, og jeg vil kalde det som en ufærdig historie, fordi:
en] rapporterne bør overveje, er den daglige valuta, konverteringsfrekvens og ikke de historiske én, som i de sidst har set på rapporten, og
b], Hvis valutaen ændres efter at give kundens finansielle oplysninger, de rapporter, der skal vise, i den ændrede valuta.
lø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.,
Take a .ay: 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 noter for at gøre tingene lettere og diskutere med BA ‘ erne og udviklerne om deres tænkning.,
dybdegående kig på acceptkriterier
forståelse af acceptkriterierne og alle de andre betingelser& regler udtømmende er endnu vigtigere end at undervurdere en brugerhistorie. Fordi hvis et krav er ufuldstændigt eller vagt, kan det tages op i den næste sprint, men hvis et acceptkriterium går glip af, kan brugerhistorien 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 do .nloader MINE Historiske udsagn meget., Hvis du observerer det omhyggeligt, er der visse specifikke muligheder til rådighed for at do .nloade dem.
Der er en mulighed for at vælge den filtype, der skal do .nloades din erklæring. Der er mulighed for at vælge, om du kun vil do .nloade Kreditterne/debet /begge dele.forestil dig nu, at produktejeren giver dig denne brugerhistorie”som kunde vil jeg do .nloade min kontoudskrift, så jeg kan se alle mine transaktioner udført i en bestemt periode”.,
Med følgende Kriterier for Accept:
- i Betragtning af, at jeg er på Hent Historiske Redegørelse Side, jeg bør vælge den periode, som jeg ønsker at downloade oversigten.i betragtning af at jeg er på siden do .nload historisk erklæring, skal jeg vælge den konto, som jeg vil do .nloade erklæringen til.
- i betragtning af at jeg er på siden do .nload historisk erklæring, bør jeg ikke have lov til at do .nloade erklæringen til fremtidig ’til’ dato.,
- i betragtning af at jeg er på siden do .nload Historical Statement, bør jeg ikke have lov til at vælge ‘fra’ dato 10 år ud over tidligere.i betragtning af at jeg do .nloader min erklæring, skal jeg kunne se den Do .nloadede fil.i betragtning af at jeg er på siden do .nload Historical Statement, skal jeg kunne do .nloade min erklæring i doc -, e .cel-og pdf-formater.
Hvis du gennemgår denne accept, mangler der 3 ting her:
- navn og format på det filnavn, der vil blive do .nloadet.,
- hvilke oplysninger (kolonnenavne) skal vises i filen.
- valglisten 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 studerer stadig godt om hvert acceptkriterium og forsøger at visualisere det med henvisning til brugerhistorien. Jo mere du studerer dybt om betingelserne og forretningsreglerne, desto mere bliver din viden om funktionen.
fejl, der findes i den indledende fase, koster intet i forhold til hvad det kan koste i ‘testing’ – fasen.,
vigtigheden af at finde uoverensstemmelser i Brugerhistoriens/Acceptkriterierne
det er altid vigtigt at dykke dybt i brugerhistorierne og acceptkriterierne på et tidligt tidspunkt, selv før udviklingen eller testen påbegyndes.
fordi det involverer:
#1) spild af tid:
Hvis uoverensstemmelserne eller fejlene i brugerhistorien / acceptkriterierne findes, når udvikling foregår eller test foregår, kan det være nødvendigt at foretage en masse omarbejdning i den resterende sprinttid.,
det sker ikke, at selvom produktejeren savnede nogle ting, vil de flytte brugerhistorien til den kommende sprint. 95% chancerne er, at de beder holdet om at udføre den nødvendige implementering og frigive den i samme sprint.derfor bliver det et mareridt for holdet, da de skal bruge ekstra tid, komme i .eekender eller arbejde sent om aftenen. Dette kan undgås ved at studere og diskutere brugerens historie/acceptkriterier så tidligt som muligt.
#2) spild af indsats:
udviklerne og QA er nødt til at revidere den implementerede kode og testcases igen., Opdatering, tilføje og fjerne som pr krav er ikke en let opgave. Det bliver for smertefuldt, da der allerede er et pres for 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 ‘Dev .a Parring’. Som glasur på kagen får du muligvis ikke 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 tilgængeligt på markedet for at gøre dette for dig, da det handler om logisk tænkning, erfaring og viden om produktet.
at deltage i præplanmødet aktivt, tale med BA, studere alene kan kun hjælpe dig med at opnå dette. Jo mere indsats du lægger, 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, først da kan kundens forventninger opnås med succes.,
har du noget nyt at dele med os om dine oplevelser med at arbejde med brugerhistorier? Venligst udtrykke dine tanker nedenfor!!
sidst opdateret: 18. januar 2021 6: 33 am
Leave a Reply