Je zit in een sprintplanning en de product owner vraagt: “Hebben we test scenarios of test cases nodig voor deze functie?” Iedereen aan tafel knikt, maar je merkt dat niet iedereen hetzelfde bedoelt.
De ene collega denkt aan een korte beschrijving van de gebruikersflow, terwijl de ander een document met twintig gedetailleerde teststappen voor zich ziet.
Dat is precies waar de verwarring zit bij test case vs test scenario. Het verschil draait om het detailniveau. Een test scenario beschrijft op hoofdlijnen wat je wilt testen, bijvoorbeeld “een klant koopt een product en betaalt met creditcard”.
Een test case legt daarentegen stap voor stap vast hoe je dat precies test, inclusief welke gegevens je invoert en welk resultaat je verwacht.
Na dit artikel weet je precies wanneer je een scenario schrijft, wanneer je een test case nodig hebt, en hoe je van het ene naar het andere komt. Met voorbeelden die je direct kunt gebruiken.
Het verschil in een oogopslag
Voordat het artikel de diepte in gaat, hier het verschil samengevat in een tabel.
| Aspect | Test scenario | Test case |
|---|---|---|
| Detailniveau | Hoofdlijnen | Gedetailleerde stappen |
| Perspectief | Business | Technische uitvoering |
| Kernvraag | Wat wil de gebruiker bereiken? | Hoe test je dat precies? |
| Voorbeeld | “Klant koopt product” | “Stap 1: selecteer product, stap 2: voeg toe aan winkelwagen…” |
De tabel geeft je een snel overzicht, maar het echte verschil wordt pas duidelijk met voorbeelden. Daarom volgt hieronder een uitleg van beide concepten.
Test scenario: het grote plaatje in een zin
Een test scenario is een korte beschrijving van wat een gebruiker wil bereiken, geschreven op hoofdlijnen vanuit een businessperspectief. Denk aan het als een samenvatting van een gebruikersreis in een of twee zinnen.
Een voorbeeld: “Een klant registreert een account, zoekt een product en rondt een bestelling af.” Dat is het hele scenario. Je beschrijft niet hoe de klant dat doet, welke knoppen diegene klikt of welke gegevens worden ingevuld, want je beschrijft alleen het doel.
Test scenarios schrijf je vroeg in het project, meestal al in de fase waarin je de eisen (requirements) verzamelt. Ze helpen je om met stakeholders af te stemmen welke gebruikersflows belangrijk zijn, zonder dat je in technische details hoeft te duiken.
Een product owner begrijpt “klant koopt product” direct, terwijl een test case met vijftien stappen en testdata eerder verwarring oplevert dan helderheid.
Maar een scenario alleen is niet genoeg om daadwerkelijk te testen. Daarvoor heb je de gedetailleerde stappen van een test case nodig.
Test case: elke stap vastgelegd
Waar een test scenario het “wat” beschrijft, legt een test case (ook wel testgeval genoemd) het “hoe” vast. Een test case bevat voorwaarden die moeten kloppen voordat je begint, exacte teststappen, specifieke testdata en het verwachte resultaat.
Neem het scenario “klant logt in en ziet het dashboard”. De bijbehorende test case ziet er dan zo uit: de voorwaarde is dat de klant bestaat in het systeem met e-mail test@voorbeeld.nl en wachtwoord Test123!. Vervolgens open je de homepage, klik je op ‘Inloggen’, vul je het e-mailadres en wachtwoord in en klik je op ‘Verzenden’. Het verwachte resultaat is dat het dashboard laadt en de gebruikersnaam rechtsboven verschijnt.
Zie je het verschil? Het scenario past in een zin. De test case heeft specifieke data, duidelijke stappen en meetbare verwachtingen.
Dat maakt test cases onmisbaar wanneer je wilt dat elke tester dezelfde test op exact dezelfde manier uitvoert, want zonder die consistentie weet je nooit zeker of een afwijking een echte bug is of een verschil in aanpak.
Nu je het verschil snapt, is de logische vraag: wanneer kies je voor welke?
Wanneer kies je voor een test scenario?
Test scenarios zijn het meest waardevol in vier situaties.
Ten eerste bij het valideren van requirements. Stel je een meeting voor met je product owner, een developer en jijzelf als tester. De product owner zegt: “Gebruikers moeten kunnen inloggen met hun Google-account.” Jij schrijft ter plekke een test scenario: “Klant logt in via Google OAuth en ziet een gepersonaliseerd dashboard.”
Direct wordt duidelijk of de requirement compleet is, want wat moet er precies gebeuren na het inloggen? Die vraag stelt het scenario vanzelf.
Ten tweede bij exploratory testing, oftewel verkennend testen. Je krijgt een nieuwe functie zonder uitgewerkte test cases, en dan werkt een scenario als kompas. “Klant uploadt een document en deelt het met een collega” geeft je richting om variaties te ontdekken, zonder dat je vastzit aan een script.
Daarnaast zijn scenarios perfect voor communicatie met stakeholders. Een product owner hoeft geen vijftien teststappen door te lezen; een scenario op hoofdlijnen volstaat voor een review.
En tot slot helpen scenarios bij het beoordelen van je testdekking (test coverage). Door al je scenarios op een rij te zetten, zie je snel welke flows gedekt zijn en waar gaten zitten.
Maar scenarios vertellen je niet hoe je iets test. Daarvoor heb je test cases nodig, en die zijn onmisbaar in heel andere situaties.
Wanneer zijn test cases onmisbaar?
Test cases komen tot hun recht wanneer detail en reproduceerbaarheid belangrijk zijn.
Bij regressietesten (regression testing) bijvoorbeeld. Sprint na sprint test je dezelfde functionaliteit opnieuw, en test cases zorgen ervoor dat elke tester exact dezelfde stappen volgt met dezelfde testdata. Zonder die consistentie weet je niet of een fout nieuw is of al eerder bestond.
Test cases zijn ook essentieel wanneer iemand anders jouw test overneemt. Stel je voor dat een junior tester jouw werk voortzet terwijl je op vakantie bent. Met een gedetailleerde test case, inclusief voorwaarden, stappen en verwachte resultaten, kan diegene direct aan de slag.
Documentatie is in dat geval kennisoverdracht.
Bovendien zijn test cases onmisbaar bij audits. In sectoren als fintech, zorg en overheid willen auditors exact zien wat je getest hebt en wat het resultaat was. Test cases bieden die traceerbaarheid, en test automation genereert dit soort rapportages vaak automatisch.
Tot slot vormen test cases de basis voor testautomatisering. Een Selenium- of Playwright-script volgt in feite de stappen van een test case. Zonder gedetailleerde cases weet je simpelweg niet wat je moet automatiseren.
Nu je weet wanneer je welke gebruikt, wordt het pas echt praktisch: hoe maak je van een scenario concrete test cases?
Van een scenario naar concrete test cases: zo doe je dat
Dit is waar het samenkomt. Je hebt een test scenario en wilt daar uitvoerbare test cases van maken. Dat doe je in vier stappen.
Begin met je scenario op hoofdlijnen. Neem bijvoorbeeld: “Klant koopt een product en betaalt met creditcard.” Dit is je uitgangspunt, puur het doel van de gebruiker zonder details.
Vervolgens identificeer je de variaties door jezelf drie vragen te stellen: wat kan goed gaan (het zogenaamde happy path, het ideale pad waarbij alles werkt)? Wat kan fout gaan?
En welke alternatieven zijn er? Voor dit checkout scenario vind je dan variaties als: alles verloopt perfect, het product is uitverkocht, de betaling mislukt, de creditcard is verlopen, en er wordt een kortingscode toegepast.
Daarna schrijf je per variatie een test case uit. De happy path test case ziet er bijvoorbeeld zo uit: de klant is ingelogd, het product “Product A” is op voorraad, de klant voegt het toe aan de winkelwagen, vult adres “Teststraat 1, Amsterdam” in, kiest creditcard als betaalmethode, vult de kaartgegevens in en plaatst de bestelling.
Het verwachte resultaat is een bevestigingspagina, een orderbevestiging per e-mail en een voorraadwijziging in het systeem.
De test case voor een uitverkocht product is veel korter: de klant zoekt een product waarvan de voorraad nul is, klikt op ‘Toevoegen aan winkelwagen’, en verwacht een melding “Product momenteel niet op voorraad” met een suggestie voor alternatieven.
Een handige vuistregel is dat een scenario gemiddeld drie tot acht test cases oplevert. Een eenvoudig login scenario komt uit op drie cases (geldige login, ongeldige login en geblokkeerd account), terwijl een complex checkout scenario makkelijk acht variaties heeft.
Laten we dit patroon nog een keer toepassen met een ander voorbeeld, zodat het goed landt.
Nog een voorbeeld: de wachtwoord reset flow
Neem het scenario: “Klant reset een vergeten wachtwoord via e-mail.” Klinkt simpel, maar ook hier komen meerdere variaties naar boven.
De happy path: de klant vult een geldig e-mailadres in, ontvangt een resetlink, klikt erop, stelt een nieuw wachtwoord in en kan daarna weer inloggen. Maar wat als het e-mailadres niet bestaat in het systeem? Dan verwacht je een foutmelding als “E-mailadres niet gevonden”.
En wat als de klant de resetlink pas na 24 uur aanklikt? Dan moet de link verlopen zijn, met een duidelijke melding “Link verlopen, vraag een nieuwe aan”. Of stel dat iemand dezelfde link een tweede keer probeert te gebruiken, dan verwacht je “Deze link is al gebruikt”.
Zo wordt een scenario van een zin vier concrete test cases. Dit multiplicatie-effect is precies waarom je beide nodig hebt: scenarios geven overzicht, test cases garanderen dat je elke variatie daadwerkelijk test.
Wil je meer leren over het ontdekken van dit soort variaties? Exploratory testing helpt je om systematisch randgevallen (edge cases) te vinden die je anders over het hoofd ziet.
Wat je morgen anders kunt doen
Het verschil tussen een test case en een test scenario is uiteindelijk helder: het scenario beschrijft wat je test, de case beschrijft hoe je het test. Beide zijn onmisbaar, want zonder scenarios mis je het overzicht en zonder cases mis je de details.
De krachtigste aanpak is om altijd te beginnen met scenarios. Stem ze af met je product owner, gebruik ze om je testdekking te beoordelen en schrijf ze op zodra requirements duidelijk worden. Werk vervolgens de belangrijkste scenarios uit naar gedetailleerde test cases, zodat je team ze kan uitvoeren, herhalen en uiteindelijk automatiseren.
Begin deze week eens met een scenario voor je volgende user story. Schrijf het in een zin, identificeer de variaties en werk er twee of drie uit naar volledige test cases. Je zult merken dat dit niet alleen je tests beter maakt, maar ook je gesprekken met stakeholders een stuk helderder.
Worstel je met het schrijven van goede test cases, of wil je sparren over hoe je dit in je team introduceert? Stuur gerust een berichtje. We denken graag vrijblijvend met je mee. Plan een gesprek
