Lästid: 7 minuter
framgången för ett projekt beror på utvecklingsgruppens förmåga att uppfylla kundens behov. Kommunikationen mellan kunden och utvecklingsteamet spelar en viktig roll för att leverera en lösning som passar produkt-och marknadskraven., Problemen uppstår om kunderna förklarar sina behov för vagt och laget kan inte förstå tydliga krav och så småningom affärsproblem bakom dem. Tänk dig att du ber ditt team att göra det möjligt för användare att söka efter en produkt i en online bokhandel efter kategorier. Du förväntar dig att ha ett tydligt gränssnitt med kategorilänkar för att klicka på dem (t.ex. fantasi, facklitteratur, Historisk, etc.) Efter två veckors utveckling, får du en sökfältet funktion där användarna måste skriva in den kategori de är intresserade av, i stället för att bläddra fördefinierade kategorier., Även om detta också fungerar, ditt ursprungliga mål var att exponera alla tillgängliga kategorier och låta användare utforska ytterligare.
det här är när högkvalitativ programvarudokumentation kan hjälpa till att undvika problemet. Användarhistorier och acceptanskriterier (AC) som huvudformat för dokumenteringskrav. En användarhistoria är en naturlig språkbeskrivning av en funktion. Det brukar åtföljas av acceptanskriterier.
acceptanskriterier (AC) är de villkor som en programvaruprodukt måste uppfylla för att accepteras av en användare, en kund eller annat system., De är unika för varje användarhistoria och definierar funktionsbeteendet från slutanvändarens perspektiv. Välskrivna acceptanskriterier hjälper till att undvika oväntade resultat i slutet av ett utvecklingsstadium och se till att alla intressenter och användare är nöjda med vad de får.
acceptanskriterier är de lägsta funktionella kraven
acceptanskriterier huvudsakliga syften
att klargöra intressenternas krav är ett mål på hög nivå. För att göra syftet med AC tydligare, låt oss bryta ner dem.,
funktion scope detalization. AC definiera gränserna för användarhistorier. De ger exakta detaljer om funktionalitet som hjälper laget att förstå om historien är klar och fungerar som förväntat.
beskriver negativa scenarier. Yor AC kan kräva att systemet känner igen osäkra lösenord ingångar och hindra en användare från att gå vidare. Ogiltigt lösenordsformat är ett exempel på ett så kallat negativt scenario när en användare gör ogiltiga ingångar eller beter sig oväntat. AC definiera dessa scenarier och förklara hur systemet måste reagera på dem.
ställa in Kommunikation., Acceptanskriterier synkroniserar klientens och utvecklingsgruppens visioner. De ser till att alla har en gemensam förståelse för kraven: utvecklare vet exakt vilken typ av beteende funktionen måste visa, medan intressenter och kunden förstår vad som förväntas av funktionen.
effektivisera acceptanstest. AC är grunden för användarhistoriken acceptanstest. Varje acceptanskriterium måste vara självständigt testbart och därmed ha en tydlig pass eller misslyckas scenarier. De kan också användas för att verifiera historien via automatiserade tester.
Har bestämt., Acceptanskriterier anger vad som exakt måste utvecklas av laget. När laget har exakta krav kan de dela användarhistorier i uppgifter som kan uppskattas korrekt.
acceptanskriterier typer och strukturer
AC kan skrivas i olika format. Det finns två vanligaste, och det tredje alternativet är att utforma ditt eget format:
- scenarioorienterad (Given/När/sedan)
- regelorienterad (checklista)
- anpassade format
eftersom det första och det andra formatet har mycket specifika strukturer fokuserar vi främst på dem., Du kan dock upptäcka att andra format passar din produkt bättre så vi kommer kortfattat att beröra dem också.
Scenarioorienterade acceptanskriterier
Scenarioorienterat format för att skriva AC kallas Given/When / Then (GWT) typ.
- med tanke på vissa förutsättningar
- när jag gör vissa åtgärder
- då förväntar jag mig ett visst resultat
detta tillvägagångssätt ärvdes från beteendedriven utveckling (BDD) och ger en konsekvent struktur som hjälper testare definiera när man ska börja och avsluta testa en viss funktion., Det minskar också den tid som spenderas på att skriva testfall som systemets beteende beskrivs i förskott.,
varje godkännandekriterium som skrivs i detta format har följande uttalanden:
- Scenario – namnet på beteendet som kommer att beskrivas
- Given – scenariets begynnande tillstånd
- när – specifik åtgärd som användaren gör
- då – resultatet av åtgärden i ”när”
- och – används för att fortsätta någon av tre tidigare uttalanden
när de kombineras täcker dessa uttalanden alla åtgärder som en användare gör
låt oss titta på några exempel.,
exempel 1
användarhistoria: som användare vill jag kunna återställa lösenordet till mitt konto, så att jag kommer att kunna komma åt mitt konto om jag glömde lösenordet.,
När: användaren valt Glömt lösenord alternativ
och: angett ett giltigt e-postmeddelande för att ta emot en länk för återställning av lösenord
då: systemet skickade länken till det angivna e-postmeddelandet
givet: användaren fick länken via e-post
När: användaren navigerade via länken som mottogs i e-post
då: systemet gör det möjligt för användaren att ställa in ett nytt lösenord
exempel 2
p>
användarhistoria: som användare vill jag kunna begära pengarna från mitt konto i ATM så att jag snabbt och på olika ställen kan ta emot pengarna från mitt konto.,
och: dispensern innehåller kontanter
När: kunden begär kontanter
då: se till att kontot debiteras
och: se till att kontanter dispenseras
och: se till att kortet returneras
acceptanskriterier 2:
givet: att kontot är övertrasserat
och: kortet är giltigt
När: kunden begär kontant betalning
då: se till att avvisningsmeddelandet visas
och: se till att kontanter inte dispenseras
regelorienterad acceptanskriterier format
i vissa fall är det svårt att passa acceptanskriterier i den givna/när / sedan strukturen., GWT skulle till exempel knappast vara användbart för följande fall:
- du arbetar med användarhistorier som beskriver funktionaliteten på systemnivå som behöver andra metoder för kvalitetssäkring.
- målgruppen för acceptanskriterier behöver inte exakta uppgifter om testscenarierna.
- GWT-scenarier passar inte för att beskriva design-och användarupplevelsebegränsningar för en funktion. Utvecklare kan sakna ett antal kritiska detaljer.
Du kan hantera dessa fall med regelorienterat AC-format.,
den regelorienterade formen innebär att det finns en uppsättning regler som beskriver beteendet hos ett system. Baserat på dessa regler kan du rita specifika scenarier.
vanligtvis ser kriterier som består med hjälp av detta formulär ut som en enkel punktlista. Låt oss ta en titt på ett exempel.
exempel
användarberättelse: som användare vill jag använda ett sökfält för att skriva in en stad, ett namn eller en gata, så att jag kunde hitta matchande hotellalternativ.,
grundläggande kriterier för godkännande av sökgränssnitt
- sökfältet placeras i översta fältet
- sökningen startar när användaren klickar på ”SÖK”
- fältet innehåller en platshållare med en gråfärgad text: ”vart ska du?”
- platshållaren försvinner när användaren börjar skriva
- Sök utförs om en användartyp i en stad, hotellnamn, gata eller alla kombinerade
- sökningen är på engelska, franska, tyska och ukrainska
- användaren kan inte skriva mer än 200 symboler
- sökningen stöder inte speciella symboler (tecken)., Om användaren har skrivit en speciell symbol, visa varningsmeddelandet: ”Sökingången kan inte innehålla speciella symboler.”
andra format
de flesta användarhistorier kan täckas med två format som nämns ovan. Du kan dock uppfinna dina egna acceptanskriterier med tanke på att de tjänar sina syften, är tydligt skrivna på vanlig engelska och kan inte misstolkas. Vissa lag använder även vanlig text.,
Ibland kan dina kriterier anges som ett exempel på systembeteende:
en enkel uppsättning AC för starka lösenord av Mark Levison för agilepainpainrelief.com
detta tillvägagångssätt ger tydliga riktlinjer för testning av lösenordsfunktioner.
ansvariga roller och hur acceptanskriterier skapas
några av kriterierna definieras och skrivs av produktägaren när han eller hon skapar eftersläpningen av produkten. Och de andra kan specificeras ytterligare av laget under användarhistorier diskussioner efter sprint planering., Det finns inga strikta rekommendationer för att välja den person som ansvarar för att skriva kriterierna. Kunden kan dokumentera dem om han eller hon har riklig teknisk och produktdokumentationskunskap. I det här fallet förhandlar kunden kriterierna med laget för att undvika ömsesidiga missförstånd. Annars skapas kriterierna av en produktägare, affärsanalytiker, kravanalytiker eller en projektledare.,
processen börjar med user story prioritering och slutar med förhandlings detaljer med hela laget
stora utmaningar och bästa praxis för att skriva acceptanskriterier
acceptanskriterier ser ut som om de är mycket lätt att skriva. Trots sina förenklade format utgör skrivandet en utmaning för många lag. Låt oss ta en djupare titt på de bästa metoderna som hjälper till att undvika vanliga misstag.
Dokumentkriterier före utveckling. Godkännandekriterier måste dokumenteras innan den faktiska utvecklingen börjar., På så sätt kommer laget sannolikt att fånga alla kundbehov i förväg. I början är det tillräckligt att ställa in kriterierna för ett litet antal användarhistorier för att fylla eftersläpningarna för två sprints (om du övar Scrum eller en liknande metod). De måste överenskommas av båda parter. Då används de dokumenterade acceptanskriterierna av utvecklare för att planera den tekniska processen.
gör inte AC för smal. Acceptanskriterier kan vara alldeles för specifika levande liten eller ingen manövrera alternativ för utvecklare. För att undvika detta, kom ihåg att AC måste förmedla avsikten men inte en slutlig lösning., Dessutom kan smal AC vara berövad av flera användarbeteenden som inte omfattas.
Håll dina kriterier uppnåeliga. Denna punkt skär nära den föregående. Effektiva acceptanskriterier definierar den rimliga minsta bit av funktionalitet som du kan leverera. Men om du ger dig för att beskriva alla små detaljer finns det risk för att ditt lag kommer att fastna med hundratals små uppgifter.
Håll AC mätbar och inte för bred. Breda acceptanskriterier gör en användarhistoria vag., Effektiva acceptanskriterier måste skissera omfattningen av arbetet så att utvecklarna kan planera och uppskatta sina ansträngningar ordentligt.
Undvik tekniska detaljer. Som vi nämnde måste acceptanskriterier skrivas på Klar engelska. Detta kommer att göra dem tydliga och lätta att förstå för alla: dina intressenter eller chefer kanske inte har teknisk bakgrund.
nå konsensus. Samma problem kan lösas på olika sätt av ett team och intressenter, beroende på deras utsiktspunkter. Se till att du har meddelat din AC till intressenter och nått en ömsesidig överenskommelse., Detsamma gäller för lagmedlemmar. Alla måste granska AC och bekräfta att de förstår och håller med varje rad.
skrivbar AC. Detta gör det möjligt för testare att kontrollera att alla krav uppfylldes. Annars kommer utvecklare inte att förstå om användarhistoriken är klar.
sista ordet
försumma inte acceptanskriterierna eftersom de – är enkla och lättillgängliga – löser flera problem samtidigt., De dokumenterar kundernas förväntningar, ger ett slutanvändarperspektiv, klargör krav och förhindrar tvetydighet och hjälper till med kvalitetssäkring att verifiera om utvecklingsmålen uppfylldes. Oavsett om du använder smidiga metoder eller inte, se till att välja det bästa formatet eller experimentera med dina egna. Olika typer av användarhistorier och så småningom funktioner kan kräva olika fromats och testa de nya som fungerar för dig är en bra praxis.