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å.
Scenario-orienterade acceptanskriterier
Scenario-orienterade formatet för att skriva AC är känd som 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.,alid
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 att kontant betalas tillbaka
Cash
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: