Acceptanskriterier enligt Givet-När-Sedan förklarade

Så här fungerar strukturen:

• Givet anger vad som redan måste vara sant innan slutanvändaren gör något. 
• När introducerar handlingen. Det är vad användaren gör eller den händelse som systemet utlöser.
• Sedan visar resultatet. Det är utfallet som bevisar att systemet reagerade korrekt.

Så skriver du acceptanskriterier enligt Given-When-Then

Så skriver du varje del så att den håller under utveckling och programvarutestning.

Givet: Ange sammanhang och förutsättningar

Givet-delen beskriver vad som redan måste vara sant. Det omfattar systemets tillstånd, användarroll, dataförhållanden och miljökonfiguration. Bra Givet-formuleringar är specifika. Undvik att skriva "Givet att användaren är inloggad" när scenariot beror på rollen. Skriv i stället "Givet att en registrerad kund med en giltig prenumeration befinner sig på sidan för kontoinställningar."

Några riktlinjer för att skriva Givet-delen:

• Ange användarrollen eller personen när det är relevant.
• Ange systemvillkor som funktionsflaggor, datatillstånd eller anslutning.
• Kombinera flera förutsättningar med "Och" i stället för att pressa in dem i en enda formulering.

När: Definiera handlingen eller utlösaren

När-delen fångar handlingen eller händelsen som utlöser beteendet du testar. Den bör beskriva en användarinteraktion eller systemhändelse, inte en sekvens. Använd aktiv form. Skriv "När kunden klickar på 'Tillämpa kupong'" i stället för "När kupongknappen klickas på." Då blir det tydligt vem som utför handlingen.

Håll den här delen kort och tydlig. Om du behöver mer än en När-formulering beskriver du troligen två separata scenarier. Dela upp dem.

Sedan: Ange det förväntade resultatet

Sedan-delen anger vad användaren ska kunna observera eller vad systemet ska göra efter handlingen. Beskriv observerbara resultat. "Sedan läses kontrollpanelen in" är svagt. "Sedan visar systemet kundens kontrollpanel inom två sekunder" går att testa. Ta med detaljer som felmeddelanden, omdirigeringsmål, dataändringar, e-postutlösare eller ändringar av användargränssnittets tillstånd.

Använd Och för att länka samman flera resultat när en enda handling leder till mer än ett observerbart resultat. Till exempel: "Sedan visas sidan med orderbekräftelsen" Och "kunden får ett bekräftelsemeddelande inom 60 sekunder."

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Create Free Account

Have an account? Log In

Exempel på Given-When-Then

Här är några exempel på acceptanskriterier enligt Given-When-Then från olika områden.

Inloggning för användare

Scenario 1: Lyckad inloggning med giltiga inloggningsuppgifter

Givet att en registrerad användare befinner sig på inloggningssidan När användaren anger en giltig e-postadress och ett korrekt lösenord och klickar på "Logga in" Sedan omdirigerar systemet användaren till dennes kontokontrollpanel

Givet-delen är avsiktligt kort eftersom scenariot inte beror på prenumerationsnivå eller kontostatus. Lägg märke till den sammansatta När-delen: att ange inloggningsuppgifter och klicka på en knapp är en logisk handling (att skicka ett inloggningsformulär), så jag håller ihop den i stället för att dela upp den i ett separat scenario för varje knapptryckning.

Scenario 2: Misslyckad inloggning med ogiltiga inloggningsuppgifter

Givet att en registrerad användare befinner sig på inloggningssidan När användaren anger en giltig e-postadress och ett felaktigt lösenord och klickar på "Logga in" Så visar systemet meddelandet "Ogiltig e-postadress eller lösenord" Och användaren stannar kvar på inloggningssidan

Så-delen anger den exakta texten i felmeddelandet. Den andra Och-delen är viktig eftersom den bekräftar att användaren inte av misstag omdirigeras någon annanstans.

Varukorg och kassa

Scenario 1: Lägga till en vara i varukorgen

Givet att en kund visar en produktsida för en vara som finns i lager När kunden klickar på "Lägg i varukorgen" Så uppdateras varukorgsikonen så att den visar en vara Och ett bekräftelsemeddelande lyder "Vara tillagd i varukorgen"

Givet-delen innehåller "finns i lager" eftersom beteendet skiljer sig för varor som är slut i lager, och det är ett separat scenario.

Scenario 2: Tillämpa en giltig rabattkod

Givet att en kund har två varor i varukorgen som tillsammans kostar $80.00 När kunden anger rabattkoden "SAVE20" och klickar på "Tillämpa" Så tillämpar systemet en rabatt på 20 % Och varukorgens totalsumma uppdateras till $64.00

De specifika dollarbeloppen gör det omöjligt att misstolka scenariot. Den här typen av rabattscenario kan hjälpa till att upptäcka ett avrundningsfel i produktion där en procentuell rabatt på en udda totalsumma resulterade i ett pris med tre decimaler. Precisionen i Givet-delen ($80.00) och Så-delen ($64.00) är det som gör scenariot värdefullt.

Lösenordsåterställning

Scenario 1: Begära återställning av lösenord med en registrerad e-postadress

Givet att en användare befinner sig på inloggningssidan När användaren klickar på "Glömt lösenordet?", anger en registrerad e-postadress och klickar på "Skicka" Så visar systemet "En länk för återställning har skickats till din e-post" Och systemet skickar ett e-postmeddelande för återställning av lösenord inom 60 sekunder

Det sammansatta När-villkoret representerar ett enda logiskt flöde: att begära en återställning. Tidsbegränsningen på 60 sekunder i Så-delen är avgörande. Utan den skulle ett återställningsmeddelande som anländer 20 minuter senare tekniskt sett "godkännas". Tidsbundna resultat är en av de vanligaste detaljerna som utelämnas.

Scenario 2: Använda en utgången återställningslänk

Givet att en användare fick ett e-postmeddelande för återställning av lösenord för mer än 24 timmar sedan När användaren klickar på återställningslänken i e-postmeddelandet Så visar systemet "Den här länken har upphört att gälla. Begär en ny återställning."

Givet-delen innehåller ett tidsvillkor, vilket tvingar fram en diskussion om hur lång giltighetstiden bör vara.

Formulärvalidering

Scenario 1: Skicka in ett formulär med obligatoriska fält som saknas

Givet att en användare befinner sig i registreringsformuläret När användaren lämnar fältet "E-post" tomt och klickar på "Skicka" Så visar systemet ett infogat felmeddelande "E-post krävs" under fältet E-post Och formuläret skickas inte in

Så-delen anger var felet visas ("under fältet E-post"), inte bara att det visas. 

Scenario 2: Överskrida teckengränsen i ett textfält

Givet att en användare fyller i fältet "Biografi" med en gräns på 500 tecken När användaren anger 501 tecken Så förhindrar systemet ytterligare inmatning Och ett meddelande lyder "Högst 500 tecken tillåtna"

GWT kontra checklistor kontra användningsfall

Här är några andra typer av acceptanskriterier och när du kan använda var och en:

Aspekt	Givet-När-Sedan	Regelorienterad checklista	Användningsfall
Struktur	Givet, När, Sedan	Punktlista med regler	Numrerade steg med flöden
Passar bäst för	Beteendescenarier, BDD	Affärsregler, UI-specifikationer	Komplexa funktioner med flera flöden
Styrkor	Testbart, automatiserbart, kontextberikat	Snabbt att skriva, lätt att överblicka	Grundligt, täcker gränsfall
Begränsningar	Omständligt för enkla ändringar	Inget scenarieflöde, svårt att automatisera	Tungrott, långsamt att underhålla
Målgrupp	Utveckling, QA, produkt	Produkt, design, intressenter	Externa team, regelefterlevnad
Omfattning	Ett beteende	En hel funktion	En hel funktion
Detaljnivå	Tre satser	Flexibel	Förvillkor, eftervillkor, utlösare och numrerade steg

Jag har märkt att användningsfall fungerar bäst när du behöver dokumentera ett system för regelefterlevnad eller lämna över det till en extern leverantör. För det dagliga sprintarbetet är givet-när-sedan mer avskalat och snabbare.

När du ska använda varje format

Rätt format beror på dina teammedlemmar, ditt projekt och din berättelse.

• Använd GWT när berättelsen handlar om användarbeteende med tydliga utlösare och resultat, när du planerar att automatisera acceptanstester eller testa scenarier med verktyg för beteendedriven utveckling (BDD), eller när du behöver att utvecklare och QA delar en exakt definition av vad som är klart (DoD).

• Använd en checklista när berättelsen omfattar UI-finputsning, enkel konfiguration, affärsregler utan ett användarflöde eller icke-funktionella krav som prestandatrösklar.

• Använd ett användningsfall när funktionen är komplex och har många förgrenade flöden, när du dokumenterar för externa team eller regelefterlevnad, eller när intressenter behöver ett formellt dokument.

Bästa praxis för Givet-När-Sedan

Här är några bästa metoder som hjälper dig att använda GWT effektivt:

• Undvik vaga eller tvetydiga formuleringar: I stället för ”Sedan laddas sidan snabbt”, skriv ”Sedan laddas sidan med sökresultat inom två sekunder.” Ersätt adjektiv som ”lämplig” eller ”relevant” med mätbara värden. Om du inte kan testa det bör du formulera om det.
• Håll scenarierna enkla och fokuserade: Följ regeln om ett beteende per scenario. Varje scenario ska testa exakt en sak. När du kombinerar flera åtgärder eller resultat skapar du testfall som är svåra att felsöka och underhålla. Om ett scenario har fler än två och-satser under sedan bör du fråga dig om du testar ett beteende eller två.
• Håll en tre-vänner-session: En tre-vänner-session är ett kort, fokuserat samtal där en produktperson (produktägare eller affärsanalytiker), en utvecklare och en testare granskar kommande berättelser tillsammans innan sprinten börjar. De skriver eller förfinar GWT-kriterierna som grupp, vilket förhindrar omarbete. 
• Upprätthåll konsekvens i terminologi och stil: Välj standardiserade termer och använd dem i varje berättelse. Om du använder ”kund” i ett scenario och ”användare” i ett annat skapar du förvirring. Skapa vid behov en liten ordlista. Använd samma meningsstruktur i dina satser.

Fem vanliga antimönster

Här är några vanliga misstag som du bör undvika när du skriver acceptanskriterier enligt givet-när-sedan:

1. Skriva implementeringsdetaljer i stället för beteende: Scenarier som "Givet att API-anropet returnerar statuskoden 200" beskriver teknisk implementering, inte användarbeteende. Skriv om dem ur användarens perspektiv: "Givet att produktkatalogen har lästs in på startsidan." Spara tekniska detaljer till testautomatiseringskoden.
2. Klämma in flera scenarier i ett: Ett scenario som testar inloggning, navigering och betalning i samma block är ett integrationstest, inte ett acceptanskriterium. Dela upp varje beteende i ett eget scenario. Du får tydligare resultat och enklare felsökning.
3. Hoppa över negativa scenarier och gränsfall:Agila utvecklingsteam skriver ofta den lyckade vägen och glömmer vad som händer när saker går fel. För varje lyckat scenario bör du fråga: vad händer om indata är ogiltig? Vad händer om nätverket kopplas bort? Vad händer om data saknas? Skriv minst ett negativt scenario per story för att upptäcka problem innan de når produktionen.
4. Behandla GWT som det enda godtagbara formatet: Använd GWT för beteenden och checklistor för allt annat. Om du tvingar in varje story i givet-när-då, inklusive ändringar av knappfärger, uppdateringar av text och infrastrukturkonfiguration, kommer du att få några absurda resultat (t.ex. ”Givet att startsidan finns, När användaren visar den, Då är teckensnittet i sidhuvudet 16 px.).
5. Skriva scenarier isolerat: Skriv inte GWT-kriterier på egen hand. Formatets värde kommer från samtalet det väcker. Om dina scenarier inte diskuteras av minst två yrkesområden innan programvaruutvecklingen börjar, använder du GWT som ett dokumentationsformat när dess verkliga styrka ligger i att vara ett samarbetsformat.

Vad händer härnäst?

Tydliga acceptanskriterier enligt givet-när-då är bara en del av att leverera framgångsrika projekt. Bygg vidare på den grunden med ett kostnadsfritt DPM-medlemskap och få tillgång till praktiska mallar, expertresurser och beprövade ramverk som hjälper dig att omvandla väldefinierade krav till smidigare leveranser och bättre resultat.