Meny

Vad är användarberättelse och acceptanskriterier (exempel)

what is user story acceptance criteria

Prova Vårt Instrument För Att Eliminera Problem

En perfekt guide till kriterier för acceptans av användarberättelser med verkliga scenarier:

I mjukvaruutvecklingsindustrin definierar ordet ”Krav” vad vårt mål är, vad kunderna behöver exakt och vad som får vårt företag att öka sin verksamhet.

Vare sig det är ett produktföretag som tillverkar mjukvaruprodukter eller ett serviceföretag som erbjuder tjänster inom olika programvarufält, den främsta basen för dem alla är 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 det kallas 'Epic', 'User Story'.

Användarberättelse och acceptanskriterier

Enligt vattenfallsmodellen ä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 i dessa metoder anges kraven för små funktioner eller funktioner eftersom produkten bereds steg för steg.

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

Låt oss besöka de grundläggande först.

Vad du kommer att lära dig:

Vad är en användarberättelse?

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

Det vanligaste standardformatet för en User Story-skapelse anges nedan:

Som en

Exempel:

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

Användarberättelse och acceptanskriterium

Vad är acceptanskriterier?

Ett acceptanskriterium är en uppsättning godkända villkor eller affärsregler som funktionaliteten eller funktionen ska uppfylla och uppfylla för att accepteras av produktägaren / intressenterna.

Det här är en mycket viktig del av slutförandet av användarberättelsen och det bör studeras av produktägaren och affärsanalytikern mycket noggrant eftersom att missa ett enda kriterium kan kosta mycket. Detta är en enkel numrerad eller punktlista.

Dess format är som följer:

' Med viss förutsättning när jag gör något så förväntar jag mig resultatet ”.

java lägger till värden i en matris

Exempel (w.r.t till ovanstående användarberättelse):

  • Låt oss överväga att jag chattar med en vän och jag borde kunna ta en bild.
  • När jag klickar på en bild bör jag kunna lägga till en bildtext till bilden innan jag skickar den.
  • Om det är något problem med att starta min telefonkamera kan ett felmeddelande som ”Kamera inte startas”. etc. bör visas i enlighet med detta.

Därför definierar användarberättelsen kravet på funktionalitet eller funktion medan acceptanskriterierna definierar 'Definition av gjort' för användarberättelsen eller kravet.

Som en kvalitetsbedömning är det mycket viktigt att förstå användarberättelsen och dess acceptanskriterier djupt med att inte ens ett enda tvivel kvarstår vid teststart. Låt oss förstå varför det är extremt viktigt att gräva djupt i användarberättelser och acceptanskriterier.

Gräva djupt i användarberättelser

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ändarberättelser.

Följande fall är mina egna verkliga upplevelser.

Fall 1:

Innan tre år arbetade jag med ett mobilapplikationsprojekt och produkten var en applikation som var designad för leveransfolk.

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 återspeglas på portalen för kurirtjänstleverantörer som DTDC, FedEx etc.

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

Problem: För en sprint har din produktägare en användarberättelse för den här mobilappen som 'Som portaladministratör borde jag kunna se signaturen som leveranspersonen har tagit vid leveransen' . Här ändras portalen (webbappen) och uppdateras för att återspegla signaturen.

Som en kvalitetsbedömning måste du verifiera om signaturen som fångas i mobilappen återspeglar som förväntat i portalen.

Om du tittar på den här användarberättelsen 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 portalens killar ser historiska leveranser?” Ska historiska data raderas? Ska vi tillåta kraschar eller fel för sådan 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 att det inte finns någon signatur ska visas.

Detta kan kallas som en miss från produktägaren eller affärsanalytikern, men detta måste göras. Att implementera en funktion framgångsrikt men att bryta något med den är inte önskvärt av kunderna. Detta måste göras tillsammans med samma användarberättelse och i samma sprint.

Fall nr 2

För 6 år sedan arbetade jag på en finansieringsansökan för pensionering (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 investeringsplaner, besparingar etc. stor period till sina kunder.

Problem: Produktägaren ger dig en användarberättelse som 'Som rådgivare vill jag se rapporten från min kund baserat på de ekonomiska uppgifterna som tillhandahålls'.

Här fanns två dolda krav och jag skulle kalla det som en ofullständig berättelse för:

till) Rapporterna bör ta hänsyn till den dagliga valutakonverteringskursen och inte den historiska som i den senast visade rapporten och

b) Om valutan ändras efter att kundens ekonomiska information har tillhandahållits 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 instämde med mig och skapade två olika berättelser för de kommande sprintarna med prioritet.

Hämtmat: 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 interoperabilitet och genom att studera användarberättelsen noggrant även om den är en 2 liner.

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

Fördjupad titt på acceptanskriterier

Att förstå acceptanskriterierna och alla andra villkor och 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ändarberättelsen i sig inte släppas.

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

Det finns ett alternativ att välja filtyp för nedladdning av ditt uttalande. Det finns ett alternativ att välja om du bara vill ladda ner Credits / Debit / båda.

Föreställ dig nu att produktägaren ger dig den här användarberättelsen '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 Ladda ner historisk redogörelse bör jag välja den period för vilken jag vill ladda ner uttalandet.
  • Med tanke på att jag är på sidan Ladda ner historisk redogörelse bör jag välja det konto som jag vill ladda ner uttalandet för.
  • Med tanke på att jag är på sidan Ladda ner historisk uttalande bör jag inte få ladda ner uttalandet för framtida ”Till” -datum.
  • Med tanke på att jag är på sidan Ladda ner historisk redogörelse bör jag inte tillåtas att välja ”Från” -datum 10 år senare.
  • Med tanke på att jag laddar ner mitt uttalande borde jag kunna se den nedladdade filen.
  • Med tanke på att jag är på sidan Ladda ner historiska uttalanden bör jag kunna ladda ner mitt uttalande i doc-, excel- och pdf-format.

Om du går igenom detta godkännande saknas tre saker här:

  • Namn och format på filnamnet som kommer att laddas ner.
  • 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 en gång i taget, men studera fortfarande bra om varje acceptanskriterium och försök att visualisera det med hänvisning till användarberättelsen. Ju mer du studerar djupt om villkoren och affärsreglerna desto mer blir din kunskap om funktionen.

Fel som hittades i det inledande skedet kostar ingenting jämfört med vad det kan kosta i teststeget.

Acceptanskriterier

Viktigheten av att hitta avvikelser i användarberättelse / acceptanskriterier

Det är alltid viktigt att göra ett djupt dyk i användarberättelserna och acceptanskriterierna i ett tidigt skede redan innan utvecklingen eller testningen påbörjas.

Eftersom det handlar om:

# 1) Slöseri med tid:

Om avvikelserna eller misstagen i användarberättelsen / acceptanskriterierna hittas när utvecklingen pågår eller testningen pågår, kan mycket omarbetning 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ändarberättelsen till den kommande sprinten. 95% chanserna är att de ber laget att göra den nödvändiga implementeringen och släppa den i samma sprint.

Därför blir det 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ändarberättelsen / acceptanskriterierna så tidigt som möjligt.

# 2) Slöseri med ansträngningar:

Utvecklarna och QA måste se över den implementerade koden och testa fall igen. Uppdatera, lägga till och ta bort enligt kraven ä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 testfasen. Om du stöter på en sådan situation, gå till 'DevQA Pairing'. Som en pricken över i kan det hända att du inte får någon ersättning för extraarbetet.

Avvikelser mellan användarberättelser och acceptanskriterier

Slutsats

Djup förståelse för User Story och acceptanskriterier kan endast uppnås genom att spendera enorm tid på att studera den.

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

Att delta aktivt i mötet före planen, prata med BA, studera på egen hand kan bara hjälpa dig att uppnå detta. Ju mer du anstränger dig, desto mer lär du dig och växer.

Var det QA: erna eller utvecklarna, alla måste vara på samma sida om användarberättelserna och deras acceptanskriterier, bara 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 User Stories? Snälla uttrycka dina tankar nedan !!

Rekommenderad läsning

^