Acceptkriterier forklaret med Givet-Når-Så

Sådan fungerer strukturen:

• Givet angiver, hvad der allerede skal være sandt, før slutbrugeren foretager sig noget. 
• Når introducerer handlingen. Det er det, brugeren gør, eller den hændelse, systemet udløser.
• Så viser resultatet. Det er det resultat, der beviser, at systemet reagerede korrekt.

Sådan skriver du givet-når-så-acceptkriterier

Sådan skriver du hver del, så den holder under udvikling og softwaretest.

Givet: Fastlæggelse af kontekst og forudsætninger

Givet-delen beskriver, hvad der allerede skal være sandt. Det omfatter systemtilstand, brugerrolle, dataforhold og miljøopsætning. Gode givet-angivelser er specifikke. Undgå at skrive "Givet brugeren er logget ind", når scenariet afhænger af rollen. Skriv i stedet "Givet en registreret kunde med et gyldigt abonnement befinder sig på siden med kontoindstillinger."

Her er nogle retningslinjer for at skrive givet-delen:

• Angiv brugerrollen eller personaen, når det er relevant.
• Angiv systembetingelser såsom funktionsflag, datatilstande eller forbindelse.
• Kombiner flere forudsætninger med "Og" i stedet for at presse dem ind i én del.

Når: Definition af handlingen eller udløseren

Når-delen beskriver den handling eller hændelse, der udløser den adfærd, du tester. Den bør beskrive én brugerinteraktion eller systemhændelse, ikke en sekvens. Brug aktivt sprog. Skriv "Når kunden klikker på 'Anvend kupon'" i stedet for "Når der klikkes på kuponknappen." Det fjerner uklarhed om, hvem der udfører handlingen.

Hold denne del kort og præcis. Hvis du har brug for mere end én når-angivelse, beskriver du sandsynligvis to separate scenarier. Opdel dem.

Så: Angivelse af det forventede resultat

Så-delen angiver, hvad brugeren bør kunne se, eller hvad systemet bør gøre efter handlingen. Beskriv observerbare resultater. "Så kontrolpanelet indlæses" er svagt. "Så systemet viser kundens kontrolpanel inden for to sekunder" kan testes. Medtag detaljer såsom fejlmeddelelser, omdirigeringsdestinationer, dataændringer, udløsning af e-mails eller ændringer i brugerfladens tilstand.

Brug Og til at kæde flere resultater sammen, når en enkelt handling giver mere end ét observerbart resultat. For eksempel "Så siden med ordrebekræftelsen vises" Og "kunden modtager en bekræftelsesmail inden for 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.

Get Free Access

Have an account? Log In

Eksempler på givet-når-så

Her er nogle eksempler på givet-når-så-acceptkriterier fra forskellige områder.

Brugerlogin

Scenarie 1: Lykket login med gyldige legitimationsoplysninger

Givet en registreret bruger befinder sig på loginsiden Når brugeren indtaster en gyldig e-mailadresse og den korrekte adgangskode og klikker på "Log ind" Så omdirigerer systemet brugeren til dennes kontokontrolpanel

Givet-delen er med vilje kort her, fordi scenariet ikke afhænger af abonnementsniveau eller kontostatus. Bemærk den sammensatte når-del: at indtaste legitimationsoplysninger og klikke på en knap er én logisk handling (indsendelse af en loginformular), så jeg holder det samlet i stedet for at opdele det i et separat scenarie for hvert tastetryk.

Scenarie 2: Mislykket login med ugyldige legitimationsoplysninger

Forudsat at en registreret bruger er på login-siden Når brugeren indtaster en gyldig e-mailadresse og en forkert adgangskode og klikker på "Log ind" Så viser systemet meddelelsen "Ugyldig e-mailadresse eller adgangskode" Og brugeren forbliver på login-siden

Så-leddet angiver den nøjagtige tekst i fejlmeddelelsen. Det andet Og-led er vigtigt, fordi det bekræfter, at brugeren ikke ved en fejl bliver omdirigeret et andet sted hen.

Indkøbskurv og betaling

Scenarie 1: Tilføjelse af en vare til indkøbskurven

Forudsat at en kunde ser en produktside med detaljer om en vare, der er på lager Når kunden klikker på "Læg i kurv" Så opdateres indkøbskurvsikonet, så det viser én vare Og en bekræftelsesmeddelelse viser teksten "Vare tilføjet til indkøbskurven"

Forudsat-leddet inkluderer "på lager", fordi adfærden er anderledes for varer, der ikke er på lager, og det er et separat scenarie.

Scenarie 2: Anvendelse af en gyldig rabatkode

Forudsat at en kunde har to varer i indkøbskurven til en samlet værdi af $80.00 Når kunden indtaster rabatkoden "SAVE20" og klikker på "Anvend" Så anvender systemet en rabat på 20% Og opdateres indkøbskurvens samlede beløb til $64.00

De specifikke dollarbeløb gør det umuligt at misforstå. Denne type rabatscenarie kan hjælpe med at opdage en afrundingsfejl i produktionen, hvor en procentbaseret rabat på et ulige beløb resulterede i en pris med tre decimaler. Præcisionen i Forudsat-leddet ($80.00) og Så-leddet ($64.00) er det, der gør scenariet værdifuldt.

Gendannelse af adgangskode

Scenarie 1: Anmodning om nulstilling af adgangskode med en registreret e-mailadresse

Forudsat at en bruger er på login-siden Når brugeren klikker på "Glemt adgangskode", indtaster en registreret e-mailadresse og klikker på "Indsend" Så viser systemet "Et link til nulstilling er blevet sendt til din e-mail" Og sender systemet en e-mail til nulstilling af adgangskoden inden for 60 sekunder

Det sammensatte Når-led repræsenterer et enkelt logisk forløb: anmodning om en nulstilling. Tidsbegrænsningen på 60 sekunder i Så-leddet er afgørende. Uden den vil en e-mail til nulstilling, der ankommer 20 minutter senere, teknisk set "bestå". Tidsafgrænsede resultater er en af de detaljer, der oftest udelades.

Scenarie 2: Brug af et udløbet link til nulstilling

Forudsat at en bruger modtog en e-mail til nulstilling af adgangskoden for mere end 24 timer siden Når brugeren klikker på nulstillingslinket i e-mailen Så viser systemet "Dette link er udløbet. Anmod venligst om en ny nulstilling."

Forudsat-leddet indeholder en tidsbetingelse, som tvinger til en samtale om, hvor lang udløbsperioden bør være.

Formularvalidering

Scenarie 1: Indsendelse af en formular med manglende obligatoriske felter

Forudsat at en bruger er på registreringsformularen Når brugeren lader feltet "E-mail" stå tomt og klikker på "Indsend" Så viser systemet en indlejret fejlmeddelelse "E-mail er påkrævet" under feltet E-mail Og formularen indsendes ikke

Så-leddet angiver, hvor fejlen vises ("under feltet E-mail"), ikke kun at den vises. 

Scenarie 2: Overskridelse af tegnbegrænsningen i et tekstfelt

Forudsat at en bruger udfylder feltet "Biografi" med en grænse på 500 tegn Når brugeren indtaster 501 tegn Så forhindrer systemet yderligere indtastning Og en meddelelse viser teksten "Der må højst være 500 tegn"

GWT vs. tjeklister vs. brugsscenarier

Her er nogle andre typer acceptkriterier, og hvornår du kan bruge hver af dem:

Aspekt	Givet-Når-Så	Regelorienteret tjekliste	Anvendelsestilfælde
Struktur	Givet, Når, Så	Punktliste med regler	Nummererede trin med forløb
Bedste anvendelse	Adfærdsscenarier, BDD	Forretningsregler, UI-specifikationer	Komplekse funktioner med flere forløb
Styrker	Testbar, automatiserbar, kontekstrig	Hurtig at skrive, nem at skimme	Grundig, dækker kanttilfælde
Begrænsninger	Omstændelig ved simple ændringer	Intet scenarieforløb, svær at automatisere	Tung, langsom at vedligeholde
Målgruppe	Udvikling, QA, produkt	Produkt, design, interessenter	Eksterne teams, regeloverholdelse
Omfang	En enkelt adfærd	Hele funktionen	Hele funktionen
Detaljeringsgrad	Tre led	Fleksibel	Forudsætninger, efterbetingelser, udløsere og nummererede trin

Jeg har erfaret, at anvendelsestilfælde fungerer bedst, når du skal dokumentere et system med henblik på lovgivningsmæssig regeloverholdelse eller overdrage det til en ekstern leverandør. Til det daglige sprintarbejde er givet-når-så mere enkelt og hurtigere.

Hvornår skal de forskellige formater bruges?

Det rigtige format afhænger af dine teammedlemmer, dit projekt og din brugerhistorie.

• Brug GWT når brugerhistorien omhandler brugeradfærd med tydelige udløsere og resultater, når du planlægger at automatisere accepttests eller teste scenarier med værktøjer til adfærdsdrevet udvikling (BDD), eller når du har brug for, at udviklere og QA deler en præcis definition af, hvornår arbejdet er færdigt (DoD).

• Brug en tjekliste når brugerhistorien omhandler finpudsning af brugergrænsefladen, enkel konfiguration, forretningsregler uden et brugerforløb eller ikke-funktionelle krav som eksempelvis ydeevnegrænser.

• Brug et anvendelsestilfælde når funktionen er kompleks med mange forgrenede forløb, når du dokumenterer til eksterne teams eller regeloverholdelse, eller når interessenter har brug for en formel registrering.

Bedste praksis for Givet-Når-Så

Her er nogle anbefalinger, der kan hjælpe dig med at bruge GWT effektivt:

• Undgå vagt eller tvetydigt sprog: Skriv ikke “Så indlæses siden hurtigt”, men skriv i stedet “Så indlæses siden med søgeresultater på højst to sekunder.” Erstat tillægsord som “passende” eller “relevant” med målbare værdier. Hvis du ikke kan teste det, skal du omformulere det.
• Hold scenarierne enkle og fokuserede: Følg reglen om én adfærd pr. scenarie. Hvert scenarie bør teste præcis én ting. Når du kombinerer flere handlinger eller resultater, skaber du testtilfælde, der er svære at fejlfinde og vedligeholde. Hvis et scenarie har mere end to og-sætninger under så, skal du spørge dig selv, om du tester ét eller to adfærdsmønstre.
• Afhold en session med tre amigos: En session med tre amigos er en kort, fokuseret samtale, hvor en produktekspert (produktejer eller forretningsanalytiker), en udvikler og en tester gennemgår kommende brugerhistorier sammen, før sprintet begynder. De skriver eller finpudser GWT-kriterierne som gruppe, hvilket forebygger ekstraarbejde. 
• Vær konsekvent i terminologi og stil: Vælg standardtermer, og brug dem konsekvent i alle brugerhistorier. Hvis du bruger “kunde” i ét scenarie og “bruger” i et andet, skaber du forvirring. Opret om nødvendigt en lille ordliste. Brug den samme sætningsstruktur i dine led.

Fem almindelige antimønstre

Her er nogle almindelige fejl, du bør undgå, når du skriver acceptkriterier med givet-når-så:

1. At skrive implementeringsdetaljer i stedet for adfærd: Scenarier som "Når API-kaldet returnerer en statuskode på 200" beskriver teknisk implementering, ikke brugeradfærd. Omskriv dem fra brugerens perspektiv: "Når produktkataloget er indlæst på hjemmesiden." Gem de tekniske detaljer til koden til testautomatisering.
2. At presse flere scenarier ind i ét: Et scenarie, der tester login, navigation og betaling i én enkelt blok, er en integrationstest og ikke et acceptkriterium. Opdel hver adfærd i sit eget scenarie. Du får tydeligere resultater og lettere fejlfinding.
3. At springe scenarier for negative og ekstreme tilfælde over: Agile udviklingsteams skriver ofte den forventede succesfulde vej og glemmer, hvad der sker, når noget går galt. Spørg for hvert succesfuldt scenarie: Hvad hvis inputtet er ugyldigt? Hvad hvis netværksforbindelsen afbrydes? Hvad hvis dataene mangler? Skriv mindst ét negativt scenarie pr. brugerhistorie for at opdage problemer, før de når produktionen.
4. At behandle GWT som det eneste acceptable format: Brug GWT til adfærd, og brug tjeklister til alt andet. Hvis du tvinger hver brugerhistorie ind i given-when-then, herunder ændringer af knapfarver, opdateringer af tekst og infrastrukturkonfiguration, ender du med nogle absurde resultater (f.eks. "Når hjemmesiden findes, Når brugeren ser den, Så er skrifttypen i overskriften 16 px.").
5. At skrive scenarier isoleret: Skriv ikke GWT-kriterier alene. Formatets værdi kommer fra den samtale, det fremkalder. Hvis dine scenarier ikke bliver drøftet af mindst to fagområder, før softwareudviklingen begynder, bruger du GWT som et dokumentationsformat, selv om dets egentlige styrke er som samarbejdsformat.

Hvad sker der nu?

Tydelige acceptkriterier baseret på given-when-then er kun én del af at levere vellykkede projekter. Byg videre på dette fundament med et gratis DPM-medlemskab, og få adgang til praktiske skabeloner, ekspertressourcer og gennemprøvede rammeværk, der hjælper med at omsætte veldefinerede krav til en mere smidig levering og bedre resultater.