Testscenario's

Metadata

Doel: Genereer een complete set testscenario's voor een feature of user story vóórdat je gaat bouwen. Happy paths, edge cases, foutafhandeling en grensgevallen — zodat je niet pas na lancering ontdekt wat er misgaat.

Aanpak: Begin bij de happy path, breid uit naar edge cases, fouten en grensgevallen. Denk vanuit de gebruiker, niet vanuit de code. Werk samen met Engineering en QA.

Output: Gestructureerde lijst van testscenario's per categorie, met verwacht gedrag en prioriteit.

---

Instructies

Fase 0: Context ophalen

Stap 1 — Check wat er al is Scan uploads, gedeelde mappen en workspace op relevante bestanden (eerdere outputs, research, data). Lees ze door.

Stap 2 — Slimme vragen stellen

• Wel context gevonden → Bevestig kort wat je ziet ("Ik zie [X], klopt dat?"). Stel alleen vragen over wat je nog mist.
• Geen context → Stel onderstaande vragen.

1. De feature: Wat is de feature of user story waar we scenario's voor schrijven?
2. Acceptance criteria: Zijn er al acceptance criteria gedefinieerd? Zo ja, welke?
3. Gebruikerscontext: Wie gebruikt dit? In welke situatie? Op welk apparaat?
4. Afhankelijkheden: Hangt deze feature af van externe systemen, APIs of andere features?
5. Bekende risico's: Zijn er al scenario's waarvan je weet dat ze lastig worden?

---

De Vier Categorieën

1. Happy Path (het ideale scenario)

De gebruiker doet alles "goed" — de standaard flow zonder afwijkingen.

Vragen om happy paths te vinden:

• "Wat is de meest voorkomende manier waarop een gebruiker dit zal gebruiken?"
• "Als alles perfect gaat, wat is dan het pad van begin tot eind?"
• "Wat is het verwachte resultaat als de gebruiker de flow voltooit?"

Format per scenario:

Scenario: [Beschrijving]
Gegeven: [Uitgangssituatie]
Wanneer: [Actie van de gebruiker]
Dan: [Verwacht resultaat]
Prioriteit: Must-test

Voorbeeld:

Scenario: Gebruiker maakt succesvol een nieuw rapport
Gegeven: Gebruiker is ingelogd en heeft minimaal 1 databron gekoppeld
Wanneer: Gebruiker klikt "Nieuw rapport", selecteert template,
         vult titel in en klikt "Opslaan"
Dan: Rapport wordt opgeslagen, gebruiker ziet bevestiging,
     rapport verschijnt in overzichtslijst
Prioriteit: Must-test

---

2. Edge Cases (uitzonderingen en grensgevallen)

Situaties die niet standaard zijn maar wel voorkomen. Hier zitten de meeste bugs.

Vragen om edge cases te vinden:

• "Wat als de gebruiker dit in een onverwachte volgorde doet?"
• "Wat als er heel weinig of heel veel data is?"
• "Wat als de gebruiker halverwege stopt en later terugkomt?"
• "Wat als twee gebruikers hetzelfde tegelijk doen?"
• "Wat als de input onverwacht lang, kort, of in een ander format is?"

Typische edge cases:

Categorie	Voorbeelden
Lege staat	Geen data, geen items, eerste gebruik
Volumes	0 items, 1 item, 1.000+ items
Gelijktijdigheid	Twee gebruikers bewerken hetzelfde tegelijk
Onderbreking	Gebruiker sluit browser halverwege, verliest verbinding
Permissies	Gebruiker zonder rechten probeert actie
Invoer	Extreem lange tekst, speciale tekens, lege velden, emoji's
Tijd	Tijdzones, zomer-/wintertijd, middernacht, schrikkeljaar
Apparaat	Mobiel, tablet, klein scherm, traag netwerk

Voorbeeld:

Scenario: Gebruiker maakt rapport zonder databron
Gegeven: Gebruiker is ingelogd maar heeft geen databron gekoppeld
Wanneer: Gebruiker klikt "Nieuw rapport"
Dan: Gebruiker ziet melding "Koppel eerst een databron" met link
     naar instellingen. Geen lege of kapotte rapportage.
Prioriteit: Hoog

---

3. Foutafhandeling (als het misgaat)

Wat gebeurt er als er technische problemen zijn of de gebruiker iets fout doet?

Vragen om foutscenario's te vinden:

• "Wat als de server niet reageert?"
• "Wat als de API van een derde partij down is?"
• "Wat als de gebruiker ongeldige data invoert?"
• "Wat als de betaling mislukt?"
• "Wat als de sessie verloopt tijdens een actie?"

Typische foutscenario's:

Categorie	Scenario	Verwacht gedrag
Netwerk	Verbinding valt weg	Duidelijke foutmelding, geen dataverlies
Server	API timeout	Retry + melding, geen eindeloos laden
Validatie	Ongeldig emailadres	Inline foutmelding bij het veld
Autorisatie	Verlopen sessie	Redirect naar login, werk bewaard
Extern systeem	Derde-partij API down	Graceful degradation, melding
Data	Corrupt of missende data	Fallback-weergave, geen crash

Voorbeeld:

Scenario: Opslaan mislukt door serverfout
Gegeven: Gebruiker heeft rapport ingevuld en klikt "Opslaan"
Wanneer: Server geeft een 500-fout
Dan: Gebruiker ziet foutmelding "Opslaan mislukt, probeer opnieuw",
     ingevulde data blijft behouden, retry-knop beschikbaar
Prioriteit: Hoog

---

4. Grensgevallen (de randen van je feature)

Waar eindigt je feature en begint de rest van het systeem?

Vragen:

• "Wat als de gebruiker iets doet dat nét buiten de scope valt?"
• "Wat als ze een onverwachte combinatie van features gebruiken?"
• "Wat als ze vanuit een andere plek in het product bij deze feature terechtkomen?"
• "Wat als ze teruggaan na een actie? (browser back-knop)"

---

Prioritering

Niet alle scenario's zijn even belangrijk. Prioriteer:

Prioriteit	Criterium	Actie
Must-test	Happy path + scenario's die dataverlies of crash veroorzaken	Altijd testen vóór release
Should-test	Veelvoorkomende edge cases en foutscenario's	Testen als er tijd is
Could-test	Zeldzame grensgevallen	Testen in regressie, niet bij elke release

---

Testscenario's Schrijven met het Team

Doe dit samen met Engineering en QA:

1. PM presenteert de feature (5 min): Wat, voor wie, waarom
2. Stille brainstorm (10 min): Iedereen schrijft scenario's per categorie
3. Delen en groeperen (10 min): Overlap verwijderen, gaps vinden
4. Prioriteren (5 min): Must/Should/Could per scenario
5. Eigenaarschap (5 min): Wie schrijft de geautomatiseerde tests?

Tip: Engineers en QA denken in edge cases die PM's missen. Designers denken in gebruikersfouten die engineers missen. De combinatie is het sterkst.

---

Output

Lever het volgende op:

1. Happy path scenario's — de standaard flows, volledig uitgeschreven
2. Edge cases — per categorie (volumes, permissies, invoer, timing, etc.)
3. Foutscenario's — per type (netwerk, server, validatie, extern systeem)
4. Grensgevallen — waar de feature raakt aan de rest van het systeem
5. Prioritering — must/should/could per scenario
6. Open vragen — scenario's die je niet kunt beoordelen zonder meer context

---

Veel Voorkomende Fouten

• Alleen happy path testen — 80% van de bugs zit in de andere 20% van de flows
• Scenario's schrijven na het bouwen — dan test je wat je hebt gebouwd, niet wat je had moeten bouwen
• Te technisch formuleren — schrijf scenario's vanuit de gebruiker, niet vanuit de database
• Foutafhandeling vergeten — "wat als het misgaat" is de helft van gebruikerservaring
• Lege staat negeren — de eerste keer dat een gebruiker iets ziet is vaak leeg. Hoe ziet dat eruit?
• Geen prioritering — 50 scenario's zonder prioriteit = niemand test ze allemaal
• Scenario's alleen door PM laten schrijven — Engineering kent de technische edge cases, QA kent de testpatronen

---

Bronnen

• Lisa Crispin & Janet Gregory — Agile Testing (2009)
• Gojko Adzic — Specification by Example (2011)
• Elisabeth Hendrickson — Explore It! (2013) — exploratory testing
• Michael Bolton — Rapid Software Testing — heuristieken voor edge cases