Gitt–Når–Så-akseptansekriterier forklart
Format: Gitt–Når–Så-kriterier definerer tydelig, testbar programvareatferd for å skape en felles forståelse blant teammedlemmene.
Struktur: Hvert scenario i formatet inkluderer kontekst, brukerens handling og det forventede resultatet i et enkelt språk.
Beste praksis: Fokuser på enkelhet, samarbeid og detaljer for å gjøre akseptansekriteriene tydeligere.
Vanlige feil: Unngå å presse flere scenarioer sammen, skrive tekniske detaljer og overse grenseverdier.
Akseptansekriterier med gitt–når–så (GWT) gir en enkel og testbar måte å beskrive hvordan programvare skal oppføre seg på, slik at utviklere, testere og interessenter har en felles forståelse. Når akseptansekriteriene er vage, kaster team bort tid på å diskutere krav, bygge feil løsning og oppdage mangler sent i utviklingen.
I denne veiledningen skal jeg bryte ned formatet gitt–når–så, vise eksempler fra virkelige situasjoner på tvers av vanlige scenarier, sammenligne det med andre tilnærminger til akseptansekriterier og dele praksiser som hjelper smidige team med å skrive klarere og mer effektive brukerhistorier.
Hva er akseptansekriterier med gitt–når–så?
Gitt–når–så er en mal i tre deler for å skrive akseptansekriterier for en brukerhistorie. Hvert scenario beskriver én del av den forventede atferden i et enkelt språk som utviklere, testere og interessenter kan lese og forstå.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Slik fungerer strukturen:
- Gitt angir hva som allerede må være sant før sluttbrukeren gjør noe.
- Når introduserer handlingen. Det er det brukeren gjør, eller hendelsen systemet utløser.
- Så viser resultatet. Det er utfallet som beviser at systemet svarte riktig.
Slik skriver du akseptansekriterier med gitt–når–så
Slik skriver du hver del slik at den holder mål under utvikling og programvaretesting.
Gitt: Angi konteksten og forhåndsbetingelsene
Gitt-leddet beskriver hva som allerede må være sant. Dette omfatter systemtilstand, brukerrolle, databetingelser og oppsett av miljøet. Gode gitt-beskrivelser er spesifikke. Unngå å skrive «Gitt at brukeren er logget inn» når scenariet avhenger av rollen. Skriv heller «Gitt at en registrert kunde med et gyldig abonnement befinner seg på siden for kontoinnstillinger.»
Noen retningslinjer for å skrive gitt-leddet:
- Angi brukerrollen eller personaen når det er relevant.
- Angi systembetingelser som funksjonsflagg, datatilstander eller tilkobling.
- Kombiner flere forhåndsbetingelser med «Og» i stedet for å presse dem inn i ett ledd.
Når: Definere handlingen eller utløseren
Når-leddet fanger opp handlingen eller hendelsen som utløser atferden du tester. Det bør beskrive én brukerinteraksjon eller systemhendelse, ikke en sekvens. Bruk aktiv form. Skriv «Når kunden klikker på «Bruk kupong»» i stedet for «Når kupongknappen klikkes». Dette fjerner uklarhet om hvem som utfører handlingen.
Hold dette leddet konsist. Hvis du trenger mer enn én når-setning, beskriver du sannsynligvis to separate scenarier. Del dem opp.
Så: Angi det forventede resultatet
Så-leddet angir hva brukeren skal observere, eller hva systemet skal gjøre etter handlingen. Beskriv observerbare resultater. «Så lastes kontrollpanelet» er svakt. «Så viser systemet kundens kontrollpanel innen to sekunder» kan testes. Ta med detaljer som feilmeldinger, mål for omdirigering, dataendringer, utløsning av e-post eller endringer i brukergrensesnittets tilstand.
Bruk Og til å koble sammen flere resultater når én handling gir mer enn ett observerbart resultat. For eksempel «Så vises siden med ordrebekreftelsen» Og «kunden mottar en bekreftelses-e-post innen 60 sekunder.»
Eksempler på gitt–når–så
Her er noen eksempler på akseptansekriterier med gitt–når–så på tvers av ulike områder.
Brukerpålogging
Scenario 1: Vellykket pålogging med gyldig påloggingsinformasjon
Gitt at en registrert bruker befinner seg på påloggingssiden Når brukeren skriver inn en gyldig e-postadresse og riktig passord og klikker på «Logg inn» Så omdirigerer systemet brukeren til kontrollpanelet for kontoen
Gitt-leddet er med hensikt kort her fordi scenariet ikke avhenger av abonnementsnivå eller kontostatus. Legg merke til det sammensatte når-leddet: å skrive inn påloggingsinformasjon og klikke på en knapp er én logisk handling (innsending av et påloggingsskjema), så jeg holder det samlet i stedet for å dele det opp i et eget scenario for hvert tastetrykk.
Scenario 2: Mislykket pålogging med ugyldig påloggingsinformasjon
Gitt at en registrert bruker er på innloggingssiden Når brukeren oppgir en gyldig e-postadresse og et feil passord og klikker på «Logg inn» Så viser systemet meldingen «Ugyldig e-postadresse eller passord» Og brukeren forblir på innloggingssiden
Så-leddet angir den nøyaktige teksten i feilmeldingen. Det andre Og-leddet er viktig fordi det bekrefter at brukeren ikke blir omdirigert til et annet sted ved en feil.
Handlekurv og betaling
Scenario 1: Legge en vare i handlekurven
Gitt at en kunde viser en produktdetaljside for en vare som er på lager Når kunden klikker på «Legg i handlekurv» Så oppdateres handlekurvikonet for å vise én vare Og en bekreftelsesmelding viser teksten «Vare lagt i handlekurven»
Gitt-leddet inkluderer «på lager» fordi oppførselen er annerledes for varer som ikke er på lager, og dette er et separat scenario.
Scenario 2: Bruke en gyldig rabattkode
Gitt at en kunde har to varer i handlekurven til en samlet verdi på $80.00 Når kunden oppgir rabattkoden «SAVE20» og klikker på «Bruk» Så gir systemet en rabatt på 20 % Og totalsummen i handlekurven oppdateres til $64.00
De spesifikke dollarbeløpene gjør det umulig å mistolke scenariet. Denne typen rabattscenario kan bidra til å avdekke en avrundingsfeil i produksjon, der en prosentbasert rabatt på en uvanlig totalsum ga en pris med tre desimaler. Presisjonen i Gitt-leddet ($80.00) og Så-leddet ($64.00) er det som gjør scenariet verdifullt.
Gjenoppretting av passord
Scenario 1: Be om tilbakestilling av passord med en registrert e-postadresse
Gitt at en bruker er på innloggingssiden Når brukeren klikker på «Glemt passord», oppgir en registrert e-postadresse og klikker på «Send inn» Så viser systemet «En kobling for tilbakestilling er sendt til e-posten din» Og sender systemet en e-post for tilbakestilling av passord innen 60 sekunder
Det sammensatte Når-leddet representerer én logisk flyt: å be om en tilbakestilling. Tidsbegrensningen på 60 sekunder i Så-leddet er avgjørende. Uten den vil en e-post for tilbakestilling som kommer 20 minutter senere, teknisk sett «bestå». Tidsavgrensede resultater er noen av detaljene som oftest utelates.
Scenario 2: Bruke en utløpt kobling for tilbakestilling
Gitt at en bruker mottok en e-post for tilbakestilling av passord for mer enn 24 timer siden Når brukeren klikker på koblingen for tilbakestilling i e-posten Så viser systemet «Denne koblingen er utløpt. Be om en ny tilbakestilling.»
Gitt-leddet inneholder en tidsbetingelse, noe som tvinger frem en diskusjon om hvor langt utløpsvinduet bør være.
Skjemavalidering
Scenario 1: Sende inn et skjema med manglende obligatoriske felt
Gitt at en bruker er i registreringsskjemaet Når brukeren lar feltet «E-post» stå tomt og klikker på «Send inn» Så viser systemet en innebygd feilmelding «E-post er obligatorisk» under feltet E-post Og skjemaet sendes ikke inn
Så-leddet angir hvor feilen vises («under feltet E-post»), ikke bare at den vises.
Scenario 2: Overskride tegnbegrensningen i et tekstfelt
Gitt at en bruker fyller ut feltet «Biografi», som har en grense på 500 tegn Når brukeren skriver inn 501 tegn Så hindrer systemet videre inntasting Og en melding viser teksten «Maksimalt 500 tegn er tillatt»
GWT sammenlignet med sjekklister og brukstilfeller
Her er noen andre typer akseptansekriterier og når du kan bruke hver av dem:
| Aspekt | Gitt–Når–Så | Regelorientert sjekkliste | Brukstilfelle |
|---|---|---|---|
| Struktur | Gitt, Når, Så | Punktliste med regler | Nummererte trinn med flyter |
| Passer best for | Atferdsscenarioer, BDD | Forretningsregler, brukergrensesnittspesifikasjoner | Komplekse funksjoner med flere flyter |
| Styrker | Testbar, automatiserbar, kontekstrik | Rask å skrive, enkel å skanne | Grundig, dekker grensetilfeller |
| Begrensninger | Omstendelig for enkle endringer | Ingen scenarioflyt, vanskelig å automatisere | Omfattende, tar tid å vedlikeholde |
| Målgruppe | Utvikling, QA, produkt | Produkt, design, interessenter | Eksterne team, samsvar |
| Omfang | Én enkelt atferd | Hele funksjonen | Hele funksjonen |
| Detaljnivå | Tre ledd | Fleksibelt | Forutsetninger, etterbetingelser, utløsere og nummererte trinn |
Jeg har erfart at brukstilfeller fungerer best når du trenger å dokumentere et system for regulatorisk samsvar eller overlevere det til en ekstern leverandør. Til daglig sprintarbeid er gitt–når–så mer effektivt og raskere.
Beste praksis for Gitt–Når–Så
Her er noen gode råd som hjelper deg med å bruke GWT effektivt:
- Unngå vagt eller tvetydig språk: I stedet for «Så lastes siden inn raskt», skriv «Så lastes siden med søkeresultater inn på under to sekunder». Erstatt adjektiver som «passende» eller «relevant» med målbare verdier. Hvis du ikke kan teste det, må du skrive det om.
- Hold scenarioene enkle og fokuserte: Følg regelen om én atferd per scenario. Hvert scenario bør teste nøyaktig én ting. Når du kombinerer flere handlinger eller resultater, lager du testtilfeller som er vanskelige å feilsøke og vedlikeholde. Hvis et scenario har mer enn to «og»-uttrykk under «så», bør du spørre deg selv om du tester én eller to atferder.
- Gjennomfør en tre-amigo-økt: En tre-amigo-økt er en kort, fokusert samtale der en produkteier eller forretningsanalytiker, en utvikler og en tester går gjennom kommende brukerhistorier sammen før sprinten begynner. De skriver eller forbedrer GWT-kriteriene som gruppe, noe som forhindrer omarbeiding.
- Vær konsekvent i terminologi og stil: Velg standardbegreper og bruk dem i alle brukerhistorier. Hvis du bruker «kunde» i ett scenario og «bruker» i et annet, skaper du forvirring. Lag en liten ordliste ved behov. Bruk samme setningsstruktur i leddene dine.
Fem vanlige antimønstre
Her er noen vanlige feil du bør unngå når du skriver akseptansekriterier med gitt–når–så:
- Å skrive implementasjonsdetaljer i stedet for atferd: Scenarier som «Gitt at API-kallet returnerer statuskoden 200» beskriver teknisk implementasjon, ikke brukerens atferd. Skriv det om fra brukerens perspektiv: «Gitt at produktkatalogen er lastet inn på hjemmesiden.» Spar de tekniske detaljene til testautomatiseringskoden.
- Å presse flere scenarier inn i ett: Et scenario som tester innlogging, navigasjon og betaling i én og samme blokk, er en integrasjonstest, ikke et akseptansekriterium. Del opp hver atferd i sitt eget scenario. Du får tydeligere resultater og enklere feilsøking.
- Å hoppe over negative scenarier og kanttilfeller:Agile utviklingsteam skriver ofte det vellykkede forløpet og glemmer hva som skjer når ting går galt. For hvert vellykkede scenario bør du spørre: Hva om inndataene er ugyldige? Hva om nettverket faller ut? Hva om dataene mangler? Skriv minst ett negativt scenario per sak for å oppdage problemer før de når produksjon.
- Å behandle GWT som det eneste akseptable formatet: Bruk GWT for atferd, og bruk sjekklister til alt annet. Hvis du tvinger hver sak inn i gitt–når–så-formatet, inkludert endringer i knappfarger, oppdateringer av tekstinnhold og infrastrukturkonfigurasjon, ender du opp med noen absurde resultater (for eksempel «Gitt at hjemmesiden finnes, når brukeren ser den, så er skriften i toppteksten 16 px.»).
- Å skrive scenarier isolert: Ikke skriv GWT-kriterier alene. Verdien i formatet kommer fra samtalen det setter i gang. Hvis scenariene dine ikke blir diskutert av minst to fagområder før programvareutviklingen starter, bruker du GWT som et dokumentasjonsformat, selv om den virkelige styrken ligger i at det er et samarbeidsformat.
Hva skjer nå?
Tydelige akseptansekriterier i gitt–når–så-formatet er bare én del av å levere vellykkede prosjekter. Bygg videre på dette grunnlaget med et gratis DPM-medlemskap, og få tilgang til praktiske maler, ressurser fra eksperter og utprøvde rammeverk som bidrar til å omsette veldefinerte krav til smidigere leveranser og bedre resultater.
