Vad är användarhistoria och acceptanskriterier (exempel)

en perfekt Guide till användar Story acceptanskriterier med verkliga scenarier:

i Mjukvaruutvecklingsindustrin definierar ordet ”krav” vad vårt mål är, vad kunderna exakt behöver och vad som gör vårt företag att öka sin verksamhet.

oavsett om det är ett produktföretag som tillverkar mjukvaruprodukter eller ett serviceföretag som erbjuder tjänster inom olika programvarufält, är den främsta basen för dem alla kravet och framgången definieras av hur väl kraven uppfylls.,

termen ”krav” har olika namn i olika projektmetoder.

I vattenfall kallas det ”krav / specifikationsdokument”, i Agile eller SCRUM kallas det ”Epic”, ”User Story”.

under Waterfall model är Kravdokumenten enorma dokument på 200 eller fler sidor eftersom hela produkten implementeras i en fas. Men detta är inte fallet med Agile / SCRUM eftersom kraven i dessa metoder ges för små funktioner eller funktioner som produkten bereds steg för steg.,

i den här artikeln har jag försökt mitt bästa för att dela alla mina 4 års erfarenhet av att arbeta med användarhistorier och deras relaterade acceptanskriterier tillsammans med enkla och enkla verkliga scenarier för din bättre förståelse.

låt oss åter besöka grunderna först.

Vad är en användarhistoria?

en användarberättelse är ett krav för alla funktioner eller funktioner som skrivs ned i en eller två rader och max upp till 5 rader. En användarhistoria är vanligtvis det enklaste möjliga kravet och handlar om en och endast en funktionalitet (eller en funktion).,

det vanligaste standardformatet för att skapa en användarhistoria anges nedan:

som ett <användarroll/kund vill jag < mål som ska uppnås> så att jag kan <orsaken till målet<486e8bad93 ” > .

exempel:

som WhatsApp-användare vill jag ha en kameraikon i chattskrivningsrutan för att fånga och skicka bilder så att jag kan klicka och dela mina bilder samtidigt med alla mina vänner.

Vad är ett Godkännandekriterium?,

ett acceptkriterium är en uppsättning accepterade villkor eller affärsregler som funktionaliteten eller funktionen bör uppfylla och uppfylla, för att accepteras av produktägaren/intressenterna.

detta är en mycket viktig del av användarhistorikkomplettering och det bör studeras av produktägaren och Affärsanalytikern mycket noggrant eftersom det kan kosta mycket att missa ett enda kriterium. Detta är en enkel numrerad eller punktlista.

dess format är som följer:

”ges vissa förutsättningar när jag gör några åtgärder då jag förväntar mig resultatet”.

exempel (w. r.,t till ovan användarhistoria):

• låt oss överväga att jag chattar med en vän och jag borde kunna fånga en bild.
• när jag klickar på en bild ska jag kunna lägga till en bildtext i bilden innan jag skickar den.
• om det finns några problem med att starta min telefonkamera, kunde ett felmeddelande som ”kamera inte startas”. osv. ska visa detta.

därför definierar användarhistoriken kravet på någon funktionalitet eller funktion medan Acceptanskriterierna definierar definitionen av klar för användarhistorien eller kravet.,

som QA är det mycket viktigt att förstå användarhistorien och dess acceptanskriterier djupt med inte ens ett enda tvivel kvar vid ”start av testning”. Framåt låt oss förstå varför det är oerhört viktigt att gräva ”djupt” i användarhistorier och acceptanskriterier.

gräva djupt i användarhistorier

till att börja med, låt oss först förstå vikten av en ”djupgående” studie av en grundläggande och grundläggande sak, dvs användarhistorier.

följande fall är mina egna verkliga erfarenheter.,

Case # 1:

innan 3 år arbetade jag på ett Mobilapplikationsprojekt och produkten var ett program som var utformat för leveranspersonalen.

du skulle ha sett en leveransperson komma till din plats för leverans. Och de har en mobiltelefon där de ber dig att ge din signatur efter leverans. Denna signatur reflekterar över portalen för budfirmor som DTDC, FedEx etc.

låt oss föreställa oss att mobilappen just lanseras och deras portaler redan finns och upp.,

Problem: för en Sprint har din produktägare en användarberättelse för den här mobilappen som ”som portaladministratör ska jag kunna se signaturen som tas av leveranspersonen vid leveranstillfället”. Här ändras portalen (webbappen) och uppdateras i enlighet med detta för att återspegla signaturen.

som QA måste du kontrollera om signaturen som fångas i mobilappen reflekteras som förväntat i portalen.,

om du tittar på den här användarhistorien ser det enkelt ut, men det finns ett dolt krav här att ” för historiska leveranser fanns det ingen signaturreflektionsfunktion, så vad ska hända om portalkillarna ser historiska leveranser?”Bör historiska data utplånas? Ska vi tillåta krascher eller fel för sådana data?

naturligtvis inte alls, detta bör hanteras nådigt.,

lösning: när respektive DB-tabeller uppdateras för att lägga till en ny kolumn för Signaturplatsen ska de gamla uppgifterna ha ETT NULL-eller 0-värde som ska kontrolleras och ett meddelande om ”ingen signatur finns” ska visas.

detta kan kallas som en miss från produktägaren eller Affärsanalytikern, men detta måste göras. Genomföra en funktion framgångsrikt men bryta något tillsammans med det är inte önskvärt av kunderna. Detta måste göras tillsammans med samma användarhistoria och i samma sprint.,

Case # 2

för 6 år sedan arbetade jag på en Pensionsplaneringsfinansieringsansökan (utan BA) som var en global applikation där finansfolk som CA, finansrådgivare kunde använda den för olika valutor för att projicera investeringsplanerna, besparingarna etc. under en stor period till sina kunder.

Problem: produktägaren ger dig en användarhistoria som ”som rådgivare vill jag se min kunds rapport baserat på de ekonomiska detaljerna som tillhandahålls”.,

här fanns det 2 dolda krav och jag skulle kalla det som en ofullständig historia eftersom:

a] rapporterna bör överväga den dagliga valutaomräkningskursen och inte den historiska som i den senast visade rapporten och

b] om valutan ändras efter att ha tillhandahållit kundens finansiella detaljer ska rapporterna visas i den ändrade valutan.

lösning: jag tog upp denna oro direkt med vår produktägare och gjorde honom medveten om att båda dessa måste göras så snart som möjligt. Han kom överens med mig och skapade 2 olika historier för de kommande sprinterna med prioritet.,

Ta bort: dessa fångades eftersom vi alla var mycket väl medvetna om produkterna, deras design, struktur etc. Sådan kunskap kan endast uppnås genom att förstå produkten helt, genom att förstå modulernas driftskompatibilitet och genom att studera användarhistorien noggrant även om det är en 2-liner.

Gör anteckningar för att göra saker enklare och diskutera med BA: s och utvecklarna om deras tänkande.,

djupgående titt på acceptanskriterier

förstå acceptanskriterier och alla andra villkor& regler uttömmande är ännu viktigare än att underskatta en användarhistoria. För om ett krav är ofullständigt eller vagt kan det tas upp i nästa sprint men om ett acceptanskriterium saknas kan användarhistoriken inte släppas.

Jag antar att vi alla skulle ha använt net banking någon gång och de flesta av oss använder det varje dag och jag laddar ner mina historiska uttalanden mycket., Om du observerar det noggrant finns det vissa specifika alternativ tillgängliga för nedladdning av dem.

det finns ett alternativ att välja vilken typ av fil som ska hämtas för ditt kontoutdrag. Det finns ett alternativ att välja om du bara vill ladda ner Krediterna /Debiterna / båda.

föreställ dig nu att produktägaren ger dig den här användarhistorien ”som kund vill jag ladda ner mitt kontoutdrag så att jag kan se alla mina transaktioner gjorda under en viss period”.,

med följande acceptanskriterier:

• med tanke på att jag är på sidan Hämta Historisk uttalande, bör jag välja den period för vilken jag vill ladda ner uttalandet.
• med tanke på att jag är på sidan Hämta historiska uttalande, Jag bör välja det konto som jag vill ladda ner uttalandet.
• med tanke på att jag är på sidan Hämta historiska uttalande, Jag bör inte tillåtas att ladda ner uttalandet för framtida ”till” datum.,
• med tanke på att jag är på sidan Hämta historiska uttalande, Jag bör inte tillåtas att välja ”från” datum 10 år längre än tidigare.
• med tanke på att jag laddar ner mitt uttalande borde jag kunna visa den nedladdade filen.
• med tanke på att jag är på sidan Hämta historiska uttalande, Jag borde kunna ladda ner mitt uttalande i doc, excel och pdf-format.

om du går igenom denna acceptans saknas 3 saker här:

• namn och format på filnamnet som hämtas.,
• vilken information (kolumnnamn) ska visas i filen.
• alternativlistan för att välja vilken typ av transaktion kunden vill ha, dvs. endast debiteringar eller endast krediter eller båda.

sådana fall kan inträffa då och då, men ändå studera väl om varje acceptanskriterier och försöka visualisera det med hänvisning till användarhistorien. Ju mer du studerar djupt om villkoren och affärsreglerna desto mer blir din kunskap om funktionen.

fel som hittades i inledningsskedet kostar ingenting jämfört med vad det kan kosta i teststadiet.,

vikten av att hitta avvikelser i användarhistoriken / Acceptanskriterierna

det är alltid viktigt att göra ett djupt dyk i användarhistorierna och acceptanskriterierna på ett tidigt stadium redan innan utvecklingen eller testningen påbörjas.

eftersom det innebär:

#1) slöseri med tid:

om avvikelserna eller misstagen i användarhistoriken / acceptanskriterierna hittas när utvecklingen pågår eller testning pågår, kan mycket omarbetningar behöva göras under den återstående sprinttiden.,

det händer inte att även om produktägaren missade några saker, kommer de att flytta användarhistorien till den kommande sprinten. 95% chansen är att de ber laget att göra det nödvändiga genomförandet och släppa det i samma sprint.

det blir därför en mardröm för laget eftersom de måste spendera extra tid, komma på helger eller arbeta sent på kvällen. Detta kan undvikas genom att studera och diskutera användarhistoriken/acceptanskriterierna så tidigt som möjligt.

#2) slöseri med ansträngningar:

utvecklarna och QA måste se över den implementerade koden och testfall igen., Uppdatering, lägga till och ta bort som per krav är inte en lätt uppgift. Det blir för smärtsamt eftersom det redan finns ett tryck att leverera i tid.

i en sådan situation finns det risk för misstag i utvecklings-eller teststadiet. Om du stöter på en sådan situation gå för ”DevQA Parning”. Som glasyr på kakan får du inte få ersättning för det extra arbetet.

slutsats

djup förståelse av användarhistoria och acceptanskriterier kan endast uppnås genom att spendera enorm tid på att studera den.,

det finns inget specifikt verktyg eller kurs på marknaden för att göra detta för dig eftersom det handlar om logiskt tänkande, erfarenhet och kunskap om produkten.

delta i Pre-plan möte aktivt, prata med BA, studera på egen hand kan bara hjälpa dig att uppnå detta. Ju mer ansträngningar du lägger desto mer lär du dig och växer.

var det QA: s eller utvecklarna, alla måste vara på samma sida om användarhistorierna och deras acceptanskriterier, först då kan kundens förväntningar uppnås framgångsrikt.,

har du något nytt att dela med oss om dina erfarenheter av att arbeta med användarhistorier? Vänligen uttrycka dina tankar nedan!!