Gegeven-Wanneer-Dan-acceptatiecriteria uitgelegd

Zo werkt de structuur:

• Gegeven beschrijft wat al waar moet zijn voordat de eindgebruiker iets doet. 
• Wanneer introduceert de actie. Dit is wat de gebruiker doet of de gebeurtenis die het systeem activeert.
• Dan beschrijft het resultaat. Dat is de uitkomst die bewijst dat het systeem correct heeft gereageerd.

Acceptatiecriteria volgens gegeven-wanneer-dan schrijven

Zo schrijf je elke clausule zodat deze standhoudt tijdens de ontwikkeling en het testen van software.

Gegeven: de context en randvoorwaarden vaststellen

De gegeven-clausule beschrijft wat al waar moet zijn. Dit omvat de systeemstatus, de gebruikersrol, gegevensvoorwaarden en de omgevingsinstellingen. Sterke gegeven-statements zijn specifiek. Schrijf niet "Gegeven dat de gebruiker is ingelogd" wanneer het scenario afhankelijk is van de rol. Schrijf in plaats daarvan "Gegeven dat een geregistreerde klant met een geldig abonnement zich op de pagina met accountinstellingen bevindt."

Enkele richtlijnen voor het schrijven van de gegeven-clausule:

• Noem de gebruikersrol of persona wanneer dat van belang is.
• Vermeld systeemvoorwaarden zoals functievlaggen, gegevenstoestanden of connectiviteit.
• Combineer meerdere randvoorwaarden met "En" in plaats van ze in één clausule te proppen.

Wanneer: de actie of trigger definiëren

De wanneer-clausule legt de actie of gebeurtenis vast die het gedrag activeert dat je test. Deze moet één gebruikersinteractie of systeemgebeurtenis beschrijven, geen reeks acties. Gebruik de actieve vorm. Schrijf "Wanneer de klant op 'Coupon toepassen' klikt" in plaats van "Wanneer op de couponknop wordt geklikt." Dit neemt de onduidelijkheid weg over wie de actie uitvoert.

Houd deze clausule beknopt. Als je meer dan één wanneer-statement nodig hebt, beschrijf je waarschijnlijk twee afzonderlijke scenario's. Splits ze op.

Dan: het verwachte resultaat specificeren

De dan-clausule beschrijft wat de gebruiker na de actie moet kunnen waarnemen of wat het systeem moet doen. Beschrijf waarneembare resultaten. "Dan wordt het dashboard geladen" is zwak. "Dan toont het systeem binnen twee seconden het dashboard van de klant" is testbaar. Neem specifieke zaken op, zoals foutmeldingen, bestemmingen voor doorverwijzingen, gegevenswijzigingen, triggers voor e-mails of wijzigingen in de gebruikersinterface.

Gebruik En om meerdere resultaten aan elkaar te koppelen wanneer één actie meer dan één waarneembaar resultaat oplevert. Bijvoorbeeld: "Dan wordt de orderbevestigingspagina weergegeven" En "de klant ontvangt binnen 60 seconden een bevestigingsmail."

Voorbeelden van gegeven-wanneer-dan

Hier volgen enkele voorbeelden van acceptatiecriteria volgens gegeven-wanneer-dan voor verschillende domeinen.

Gebruikersaanmelding

Scenario 1: geslaagde aanmelding met geldige inloggegevens

Gegeven dat een geregistreerde gebruiker zich op de aanmeldpagina bevindt Wanneer de gebruiker een geldig e-mailadres en correct wachtwoord invoert en op "Aanmelden" klikt Dan leidt het systeem de gebruiker door naar diens accountdashboard

De gegeven-clausule is hier bewust beknopt, omdat het scenario niet afhankelijk is van het abonnementsniveau of de accountstatus. Let op de samengestelde wanneer-clausule: inloggegevens invoeren en op een knop klikken is één logische actie (een aanmeldformulier verzenden), dus ik houd deze bij elkaar in plaats van voor elke toetsaanslag een afzonderlijk scenario te maken.

Scenario 2: mislukte aanmelding met ongeldige inloggegevens

Gegeven een geregistreerde gebruiker zich op de inlogpagina bevindt Wanneer de gebruiker een geldig e-mailadres en een onjuist wachtwoord invoert en op "Inloggen" klikt Dan geeft het systeem het bericht "Ongeldig e-mailadres of wachtwoord" weer En blijft de gebruiker op de inlogpagina

De Dan-clausule specificeert de exacte tekst van het foutbericht. De tweede En-clausule is belangrijk omdat deze bevestigt dat de gebruiker niet per ongeluk ergens anders naartoe wordt doorgestuurd.

Winkelwagen en afrekenen

Scenario 1: Een artikel aan de winkelwagen toevoegen

Gegeven een klant een productdetailpagina voor een artikel dat op voorraad is bekijkt Wanneer de klant op "Aan winkelwagen toevoegen" klikt Dan wordt het winkelwagenpictogram bijgewerkt om één artikel weer te geven En luidt een bevestigingsbericht "Artikel aan winkelwagen toegevoegd"

De Gegeven-clausule bevat "op voorraad", omdat het gedrag voor artikelen die niet op voorraad zijn anders is en dat een apart scenario is.

Scenario 2: Een geldige kortingscode toepassen

Gegeven een klant twee artikelen in de winkelwagen heeft met een totaal van $80.00 Wanneer de klant de kortingscode "SAVE20" invoert en op "Toepassen" klikt Dan past het systeem een korting van 20% toe En wordt het totaal van de winkelwagen bijgewerkt naar $64.00

De specifieke dollarbedragen maken verkeerde interpretatie onmogelijk. Dit soort kortingsscenario kan helpen een afrondingsfout in productie op te sporen waarbij een procentuele korting op een oneven totaal een prijs met drie decimalen opleverde. De precisie in de Gegeven-clausule ($80.00) en de Dan-clausule ($64.00) maakt het scenario waardevol.

Wachtwoordherstel

Scenario 1: Een wachtwoordreset aanvragen met een geregistreerd e-mailadres

Gegeven een gebruiker zich op de inlogpagina bevindt Wanneer de gebruiker op "Wachtwoord vergeten" klikt, een geregistreerd e-mailadres invoert en op "Verzenden" klikt Dan geeft het systeem "Er is een resetlink naar je e-mailadres verzonden" weer En verzendt het systeem binnen 60 seconden een e-mail voor het opnieuw instellen van het wachtwoord

De samengestelde Wanneer hier vertegenwoordigt één logische stroom: een reset aanvragen. De tijdsbeperking van 60 seconden in de Dan-clausule is essentieel. Zonder deze beperking slaagt een reset-e-mail die 20 minuten later aankomt technisch gezien. Tijdgebonden resultaten zijn een van de vaakst weggelaten details.

Scenario 2: Een verlopen resetlink gebruiken

Gegeven een gebruiker meer dan 24 uur geleden een e-mail voor het opnieuw instellen van het wachtwoord heeft ontvangen Wanneer de gebruiker op de resetlink in de e-mail klikt Dan geeft het systeem "Deze link is verlopen. Vraag een nieuwe reset aan." weer

De Gegeven-clausule bevat een tijdsvoorwaarde, waardoor een gesprek nodig is over hoe lang de geldigheidsduur moet zijn.

Formuliervalidatie

Scenario 1: Een formulier met ontbrekende verplichte velden verzenden

Gegeven een gebruiker zich op het registratieformulier bevindt Wanneer de gebruiker het veld "E-mailadres" leeg laat en op "Verzenden" klikt Dan geeft het systeem een inline foutbericht "E-mailadres is verplicht" weer onder het veld E-mailadres En wordt het formulier niet verzonden

De Dan-clausule specificeert waar de fout verschijnt ("onder het veld E-mailadres"), niet alleen dat deze verschijnt. 

Scenario 2: De tekenlimiet van een tekstveld overschrijden

Gegeven een gebruiker het veld "Biografie" invult met een limiet van 500 tekens Wanneer de gebruiker 501 tekens invoert Dan voorkomt het systeem verdere invoer En luidt een bericht "Maximaal 500 tekens toegestaan"

GWT versus checklists versus gebruiksscenario's

Hier zijn enkele andere typen acceptatiecriteria en wanneer je elk type kunt gebruiken:

Ik heb gemerkt dat gebruiksscenario's het beste werken wanneer je een systeem moet documenteren voor naleving van regelgeving of moet overdragen aan een externe leverancier. Voor dagelijks sprintwerk is Given-When-Then beknopter en sneller.

Wanneer gebruik je elk formaat?

\u003cspan style=\u0022font-weight: 400;\u0022\u003eHet juiste formaat hangt af van je teamleden, je project en je gebruikersverhaal.\u003c/span\u003e
\u003cul\u003e
\t\u003cli style=\u0022font-weight: 400;\u0022 aria-level=\u00221\u0022\u003e\u003cb\u003eGebruik GWT\u003c/b\u003e\u003cspan style=\u0022font-weight: 400;\u0022\u003e wanneer het gebruikersverhaal gebruikersgedrag met duidelijke triggers en resultaten omvat, wanneer je acceptatietests of testscenario’s wilt automatiseren met hulpmiddelen voor gedragsgestuurde ontwikkeling (BDD), of wanneer je wilt dat ontwikkelaars en QA een nauwkeurige definitie van gereed (DoD) delen.\u003c/span\u003e\u003c/li\u003e
\u003c/ul\u003e
\u003cul\u003e
\t\u003cli style=\u0022font-weight: 400;\u0022 aria-level=\u00221\u0022\u003e\u003cb\u003eGebruik een checklist\u003c/b\u003e\u003cspan style=\u0022font-weight: 400;\u0022\u003e wanneer het gebruikersverhaal betrekking heeft op UI-verfijning, eenvoudige configuratie, bedrijfsregels zonder gebruikersstroom of niet-functionele vereisten zoals prestatiedrempels.\u003c/span\u003e\u003c/li\u003e
\u003c/ul\u003e
\u003cul\u003e
\t\u003cli style=\u0022font-weight: 400;\u0022 aria-level=\u00221\u0022\u003e\u003cb\u003eGebruik een gebruiksscenario\u003c/b\u003e\u003cspan style=\u0022font-weight: 400;\u0022\u003e wanneer de functie complex is en veel vertakkende processtromen heeft, wanneer je documentatie opstelt voor externe teams of naleving van regelgeving, of wanneer belanghebbenden een formeel verslag nodig hebben.\u003c/span\u003e\u003c/li\u003e
\u003c/ul\u003e

Beste werkwijzen voor Given-When-Then

Hier volgen enkele beste werkwijzen om GWT effectief te gebruiken:

• Vermijd vage of dubbelzinnige taal: Schrijf in plaats van “Daarna wordt de pagina snel geladen” bijvoorbeeld “Daarna wordt de pagina met zoekresultaten binnen twee seconden geladen.” Vervang bijvoeglijke naamwoorden zoals “geschikt” of “relevant” door meetbare waarden. Als je het niet kunt testen, herschrijf het dan.
• Houd scenario's eenvoudig en gericht: Volg de regel één gedrag per scenario. Elk scenario moet precies één ding testen. Wanneer je meerdere acties of resultaten combineert, maak je testgevallen die moeilijk te debuggen en te onderhouden zijn. Als een scenario meer dan twee then-instructies bevat, vraag jezelf dan af of je één of twee gedragingen test.
• Houd een drie-amigosessie: Een drie-amigosessie is een kort, gericht gesprek waarin een productmedewerker (product owner of bedrijfsanalist), een ontwikkelaar en een tester samen aankomende gebruikersverhalen beoordelen voordat de sprint begint. Ze schrijven de GWT-criteria als groep of scherpen deze aan, waardoor herwerk wordt voorkomen. 
• Wees consistent in terminologie en stijl: Kies standaardtermen en gebruik deze in elk gebruikersverhaal. Als je in het ene scenario “klant” gebruikt en in een ander “gebruiker”, zorg je voor verwarring. Maak indien nodig een kleine woordenlijst. Gebruik dezelfde zinsstructuur in je clausules.

Vijf veelvoorkomende antipatronen

Hier volgen enkele veelvoorkomende fouten die je moet vermijden bij het schrijven van acceptatiecriteria volgens Given-When-Then:

1. Implementatiedetails schrijven in plaats van gedrag: Scenario's zoals "Gegeven dat de API-aanroep een statuscode 200 retourneert" beschrijven de technische implementatie, niet het gedrag van de gebruiker. Herschrijf dit vanuit het perspectief van de gebruiker: "Gegeven dat de productcatalogus op de homepage is geladen." Bewaar technische details voor de testautomatiseringscode.
2. Meerdere scenario's in één scenario proppen: Een scenario waarin in één blok het inloggen, de navigatie en het afrekenen wordt getest, is een integratietest en geen acceptatiecriterium. Splits elk gedrag op in een afzonderlijk scenario. Zo krijg je duidelijkere resultaten en wordt het eenvoudiger om fouten op te sporen.
3. Negatieve scenario's en scenario's voor uitzonderingssituaties overslaan:Agile ontwikkelteams schrijven vaak het ideale pad uit en vergeten wat er gebeurt wanneer dingen misgaan. Vraag bij elk succesvol scenario: wat als de invoer ongeldig is? Wat als de netwerkverbinding wegvalt? Wat als de gegevens ontbreken? Schrijf ten minste één negatief scenario per gebruikersverhaal om problemen op te sporen voordat ze de productieomgeving bereiken.
4. GWT behandelen als de enige aanvaardbare indeling: Gebruik GWT voor gedrag en gebruik checklists voor al het overige. Als je elk gebruikersverhaal in gegeven-wanneer-dan-vorm dwingt, inclusief wijzigingen in knopkleuren, tekstupdates en infrastructuurconfiguratie, krijg je uiteindelijk absurde resultaten (bijv. “Gegeven dat de homepage bestaat, Wanneer de gebruiker deze bekijkt, Dan is het lettertype van de koptekst 16px”).
5. Scenario's afzonderlijk schrijven: Schrijf GWT-criteria niet alleen. De waarde van deze indeling komt voort uit het gesprek dat ermee wordt uitgelokt. Als je scenario's niet door ten minste twee disciplines worden besproken voordat de softwareontwikkeling begint, gebruik je GWT als documentatie-indeling, terwijl de echte kracht ervan juist ligt in de toepassing als samenwerkingsindeling.

Wat is de volgende stap?

Duidelijke acceptatiecriteria volgens gegeven-wanneer-dan vormen slechts één onderdeel van het succesvol opleveren van projecten. Bouw voort op die basis met een gratis DPM-lidmaatschap en krijg toegang tot praktische sjablonen, deskundige bronnen en beproefde raamwerken die helpen om goed gedefinieerde vereisten om te zetten in een soepelere oplevering en betere resultaten.