Leer acceptatietests te maken uit prompts door elk featureverzoek om te zetten in 5–10 duidelijke scenario's die happy paths en randgevallen dekken zonder opgeblazen testsets.
Chat-achtige feature-prompts lijken helder omdat ze lezen als een gesprek. Maar ze stoppen vaak keuzes, regels en uitzonderingen in een paar vriendelijke zinnen. De hiaten komen pas naar voren als iemand de feature echt gebruikt.
De meeste prompts vertrouwen stilletjes op aannames: wie mag de actie uitvoeren, wat telt als “succes” (opgeslagen, verzonden, gepubliceerd, betaald), wat gebeurt er als data ontbreekt, en wat de gebruiker moet zien als iets faalt. Ze verbergen ook vage standaarden zoals wat “snel genoeg” of “veilig genoeg” betekent.
Ambiguïteit blijkt meestal laat als bugs en herstelwerk. Een ontwikkelaar bouwt wat hij denkt dat de prompt bedoelt, een reviewer keurt het goed omdat het er goed uitziet, en dan lopen gebruikers tegen vreemde gevallen aan: dubbele inzendingen, tijdzones, gedeeltelijke data of permissieconflicten. Later herstellen kost meer omdat het vaak code, UI-tekst en soms het datamodel raakt.
Kwaliteit vereist geen enorme testsets. Het betekent dat je op normale wijze en onder voorspelbare belasting vertrouwen hebt in de feature. Een kleine set goed gekozen scenario's geeft dat vertrouwen zonder honderden tests.
Een praktische definitie van kwaliteit voor prompt-gebouwde features:
Dat is het doel van het omzetten van prompts naar acceptatiescenario's: neem een vage aanvraag en verander die in 5–10 checks die de verborgen regels vroegtijdig aan het licht brengen. Je probeert niet alles te testen. Je probeert de fouten te vangen die daadwerkelijk gebeuren.
Als je bouwt vanuit een snelle prompt in een chat-gedreven tool zoals Koder.ai, kan de output compleet lijken terwijl randregels worden overgeslagen. Een strakke set scenario's dwingt die regels te benoemen terwijl veranderingen nog goedkoop zijn.
Een acceptatietestscenario is een korte, in gewone taal beschreven beschrijving van een gebruikersactie en het resultaat dat ze zouden moeten zien.
Blijf op het oppervlak: wat de gebruiker kan doen en wat het product toont of verandert. Vermijd interne details zoals databasetabellen, API-aanroepen, achtergrondjobs of welk framework is gebruikt. Die details kunnen later belangrijk zijn, maar ze maken scenario's broos en moeilijker om overeenstemming over te bereiken.
Een goed scenario is ook onafhankelijk. Het moet makkelijk morgen draaiend te krijgen zijn in een schone omgeving, zonder dat een ander scenario eerst is uitgevoerd. Als een scenario afhankelijk is van voorafgaande staat, zeg dat dan duidelijk in de setup (bijvoorbeeld: “de gebruiker heeft al een actief abonnement”).
Veel teams gebruiken Given–When–Then omdat het duidelijkheid afdwingt zonder scenario's in een volledig spec te veranderen.
Een scenario is meestal “klaar” wanneer het één doel heeft, een duidelijke begintoestand, een concrete actie en een zichtbaar resultaat. Het moet binair zijn: iedereen in het team kan na uitvoering “pass” of “fail” zeggen.
Voorbeeld: “Given een ingelogde gebruiker zonder opgeslagen betaalmethode, when ze Pro kiezen en betaling bevestigen, then zien ze een succesmelding en staat het plan als Pro in hun account.”
Als je bouwt in een chat-first builder zoals Koder.ai, houd dan dezelfde regel aan: test het gedrag van de gegenereerde app (wat de gebruiker ervaart), niet hoe het platform de code produceerde.
Het beste formaat is datgene dat mensen zullen schrijven en lezen. Als de helft van het team lange verhalen gebruikt en de andere helft korte bullets schrijft, krijg je hiaten, duplicaten en discussies over woordkeuze in plaats van kwaliteit.
Given–When–Then werkt goed wanneer de feature interactief en stateful is. Een eenvoudige tabel werkt goed wanneer je invoer-uitvoerregels hebt en veel vergelijkbare gevallen.
Als je team verdeeld is, kies één formaat voor 30 dagen en stel bij als dat nodig is. Als reviewers blijven vragen “wat ziet succes eruit?”, is dat meestal een teken om naar Given–When–Then te gaan. Als scenario's te lang worden, is een tabel vaak gemakkelijker te scannen.
Wat je ook kiest, standaardiseer het. Houd dezelfde koppen, dezelfde tijdsvorm en hetzelfde detailniveau. Spreek ook af wat je níet opneemt: pixel-perfecte UI-details, implementatie-internals en databasediscussies. Scenario's moeten beschrijven wat een gebruiker ziet en wat het systeem garandeert.
Zet scenario's waar werk al gebeurt en houd ze dicht bij de feature.
Veelvoorkomende opties zijn ze naast de productcode bewaren, in je tickets onder een “Acceptance scenarios”-sectie, of in een gedeelde doc-ruimte met één pagina per feature. Als je Koder.ai gebruikt, kun je scenario's ook in Planning Mode bewaren zodat ze bij de buildgeschiedenis blijven, samen met snapshots en rollback-punten.
Het belangrijkste is dat ze doorzoekbaar zijn, één bron van waarheid vormen en dat scenario's vereist zijn voordat ontwikkeling als “gestart” wordt beschouwd.
Begin met het herschrijven van de prompt als een gebruikersdoel plus een duidelijke finishlijn. Gebruik één zin voor het doel (wie wil wat), en vervolgens 2–4 succescriteria die je kunt verifiëren zonder discussie. Als je geen zichtbaar resultaat kunt aanwijzen, heb je nog geen test.
Haal de prompt daarna uiteen in inputs, outputs en regels. Inputs zijn wat de gebruiker levert of selecteert. Outputs zijn wat het systeem toont, opslaat, verzendt of blokkeert. Regels zijn de “alleen als” en “moet”-uitspraken die tussen de regels staan.
Controleer vervolgens waarvan de feature afhankelijk is voordat het kan werken. Hier verbergen zich vaak scenario-hiaten: vereiste data, gebruikersrollen, permissies, integraties en systeemtaties. Als je een app bouwt in Koder.ai, geef dan bijvoorbeeld aan of de gebruiker moet zijn ingelogd, een project moet hebben aangemaakt, of aan plan- of toegangsvereisten moet voldoen voordat de actie kan plaatsvinden.
Schrijf nu de kleinste set scenario's die bewijst dat de feature werkt: meestal 1–2 happy paths en daarna 4–8 randgevallen. Houd elk scenario gefocust op één reden waarom het kan falen.
Goede randgevallen om te kiezen (alleen wat bij de prompt past): ontbrekende of ongeldige invoer, permissiemismatch, statusconflicten zoals “al ingediend”, externe afhankelijkheidsproblemen zoals timeouts, en herstelgedrag (duidelijke fouten, veilige retry, geen gedeeltelijke opslag).
Sluit af met een korte “wat kan er misgaan?”-ronde. Zoek naar stille fouten, verwarrende meldingen en plekken waar het systeem verkeerde data kan creëren.
Een happy path scenario is de kortste, meest normale route waarbij alles goed gaat. Als je het opzettelijk saai houdt, wordt het een betrouwbare baseline die randgevallen later gemakkelijker maakt om te herkennen.
Noem de standaardgebruiker en standaarddata. Gebruik een echte rol, niet “Gebruiker”: “Ingelogde klant met geverifieerd e-mailadres” of “Admin met bewerkingsrechten voor facturering.” Definieer vervolgens de kleinste voorbeelddata die zinvol is: één project, één item in een lijst, één opgeslagen betaalmethode. Dit houdt scenario's concreet en vermindert verborgen aannames.
Schrijf eerst het kortste pad naar succes. Verwijder optionele stappen en alternatieve flows. Als de feature “Taak aanmaken” is, zou de happy path geen filteren, sorteren of nabewerken na creatie moeten bevatten.
Een simpele manier om het compact te houden is vier dingen te bevestigen:
Voeg daarna één variant toe die slechts één variabele verandert. Kies de variabele die het meest waarschijnlijk later breekt, zoals “titel is lang” of “gebruiker heeft geen bestaande items”, en laat de rest gelijk.
Voorbeeld: als je prompt zegt “Voeg een ‘Snapshot created’-toast toe na het opslaan van een snapshot”, dan is de happy path: gebruiker klikt op Create Snapshot, ziet een laadstate, krijgt “Snapshot created” en de snapshot verschijnt in de lijst met de juiste timestamp. Een één-variabele-variant zou hetzelfde zijn, maar met een lege naam en een duidelijke standaardnaamregel.
Randgevallen zijn waar de meeste bugs zich verbergen, en je hebt geen enorme suite nodig om ze te vangen. Voor elke feature-prompt kies je een kleine set die reëel gedrag en echte faalwijzen reflecteert.
Veelvoorkomende categorieën om uit te putten:
Niet elke feature heeft elk type nodig. Een zoekveld geeft meer om te maken met invoer; een betaalflow met integratie- en dataproblemen.
Kies randgevallen die bij risico passen: hoge kosten bij falen (geld, security, privacy), hoge frequentie, makkelijk te breken flows, bekende bugs of problemen die moeilijk achteraf te detecteren zijn.
Voorbeeld: bij “gebruiker verandert abonnement” leveren scenario's vaak veel waarde zoals sessie-expiratie tijdens afrekenen, dubbelklikken op “Bevestig”, en een payment-provider-timeout die ervoor zorgt dat het plan ongewijzigd blijft terwijl een verwarrende melding wordt getoond.
Voorbeeld feature-prompt (in gewone taal):
“Als ik iets kapot maak, wil ik mijn app terugzetten naar een vorige snapshot zodat de laatst werkende versie weer live staat.”
Hieronder een compacte set scenario's. Elk scenario is kort, maar legt een uitkomst vast.
S1 [Must-have] Terugzetten naar meest recente snapshot
Given ik ben ingelogd en ik bezit de app
When ik kies “Rollback” en bevestig
Then wordt de vorige snapshot gedeployed en toont de appstatus de nieuwe versie als actief
S2 [Must-have] Terugzetten naar een specifieke snapshot
Given ik bekijk de snapshotlijst voor mijn app
When ik selecteer snapshot “A” en bevestig rollback
Then wordt snapshot “A” de actieve versie en zie ik wanneer deze is aangemaakt
S3 [Must-have] Niet toegestaan (auth)
Given ik ben ingelogd maar ik heb geen toegang tot deze app
When ik probeer terug te zetten
Then zie ik een toegangs-fout en start er geen rollback
S4 [Must-have] Snapshot niet gevonden (validatie)
Given een snapshot-ID bestaat niet (of is verwijderd)
When ik probeer ernaar terug te zetten
Then krijg ik een duidelijke “snapshot niet gevonden”-melding
S5 [Must-have] Dubbele inzending (duplicaten)
Given ik klik snel twee keer op “Bevestig rollback”
When het tweede verzoek wordt verstuurd
Then draait er slechts één rollback en zie ik één resultaat
S6 [Must-have] Deploy faalt (fouten)
Given de rollback is gestart
When de deployment faalt
Then blijft de huidige actieve versie live en wordt de fout getoond
S7 [Nice-to-have] Timeout of verloren verbinding
Given mijn verbinding valt weg tijdens de rollback
When ik de pagina vernieuw
Then kan ik zien of rollback nog bezig is of voltooid is
S8 [Nice-to-have] Al op die snapshot
Given snapshot “A” is al actief
When ik probeer terug te zetten naar snapshot “A”
Then krijg ik te horen dat er niets veranderd is en start er geen nieuwe deployment
Elk scenario beantwoordt drie vragen: wie doet het, wat doen ze, en wat moet daarna waar zijn.
Het doel is niet “alles testen”. Het doel is de risico's te dekken die gebruikers schade doen, zonder een stapel scenario's te creëren die niemand uitvoert.
Een praktische truc is scenario's te labelen naar hoe je ze zult gebruiken:
Beperk jezelf tot één scenario per onderscheidend risico. Als twee scenario's om dezelfde reden falen, heb je waarschijnlijk maar één nodig. “Ongeldige e-mailformat” en “ontbrekende e-mail” zijn verschillende risico's. Maar “ontbrekende e-mail in Stap 1” en “ontbrekende e-mail in Stap 2” kunnen hetzelfde risico zijn als de regel identiek is.
Vermijd ook het dupliceren van UI-stappen over veel scenario's. Houd de herhaalde delen kort en focus op wat verandert. Dit is nog belangrijker bij chat-gebaseerde builders zoals Koder.ai, omdat de UI kan verschuiven terwijl de bedrijfsregel hetzelfde blijft.
Bepaal tenslotte wat je nu controleert versus later. Sommige checks zijn beter handmatig in het begin en later te automatiseren zodra de feature stabiliseert:
Een scenario moet je beschermen tegen verrassingen, niet beschrijven hoe het team van plan is de feature te bouwen.
De meest voorkomende fout is een gebruikersdoel in een technische checklist veranderen. Als het scenario zegt “API retourneert 200” of “tabel X heeft kolom Y”, bindt het je vast aan één ontwerp en bewijst het nog steeds niet dat de gebruiker kreeg wat hij nodig had.
Een ander probleem is meerdere doelen in één lang scenario stoppen. Het leest als een volledige reis, maar als het faalt weet niemand waarom. Eén scenario moet één vraag beantwoorden.
Wees op je hoede voor randgevallen die slim klinken maar niet reëel zijn. “Gebruiker heeft 10 miljoen projecten” of “netwerk valt elke 2 seconden weg” komen zelden overeen met productie en zijn moeilijk reproduceerbaar. Kies randgevallen die je in minuten kunt opzetten.
Vermijd ook vage uitkomsten als “werkt”, “geen fouten” of “succesvol afgerond”. Die woorden verbergen de exacte resultaten die je moet verifiëren.
Als je iets bouwt zoals Koder.ai's “export source code”-feature, is een zwak scenario: “Wanneer gebruiker op export klikt, zippt het systeem de repo en retourneert 200.” Het test een implementatie, niet de belofte.
Een beter scenario is: “Given een project met twee snapshots, when de gebruiker exporteert, then bevat de download de code van de huidige snapshot en registreert het exportlog wie exporteerde en wanneer.”
Vergeet de “nee”-paden niet: “Given een gebruiker zonder exportpermissie, when ze proberen te exporteren, then is de optie verborgen of geblokkeerd en wordt er geen exportrecord aangemaakt.” Eén regel kan zowel security als data-integriteit beschermen.
Voordat je een scenario-set als “klaar” beschouwt, lees hem als een kritische gebruiker en als een database. Als je niet kunt vertellen wat waar moet zijn voordat de test start, of wat “succes” precies betekent, is het niet klaar.
Een goede set is klein maar specifiek. Je moet het aan iemand kunnen geven die de feature niet schreef en dezelfde resultaten krijgen.
Gebruik deze korte controle om scenario's goed te keuren (of terug te sturen):
Als je scenario's genereert in een chat-based builder zoals Koder.ai, houd ze aan dezelfde standaard: geen vage “werkt zoals verwacht.” Vraag om observeerbare outputs en opgeslagen veranderingen, en keur alleen goed wat je kunt verifiëren.
Maak het schrijven van scenario's een echte stap in je proces, niet een opruimtaak aan het eind.
Schrijf scenario's vóór de implementatie begint, terwijl de feature nog goedkoop te wijzigen is. Dit dwingt het team om de ongemakkelijke vragen vroeg te beantwoorden: wat betekent “succes”, wat gebeurt er bij foute input, en wat ondersteunen we nog niet.
Gebruik scenario's als je gedeelde definitie van “done.” Product is eigenaar van intentie, QA van het risico-denken en engineering van haalbaarheid. Wanneer alle drie hetzelfde scenario-set kunnen lezen en het ermee eens zijn, voorkom je dat je iets uitbrengt dat “af” is maar niet acceptabel.
Een workflow die in de meeste teams standhoudt:
Als je in Koder.ai bouwt, kan het helpen scenario's eerst te schrijven en dan Planning Mode te gebruiken om elk scenario aan schermen, dataregels en gebruikerszichten te koppelen voordat je code genereert of wijzigt.
Voor risicovolle wijzigingen: neem een snapshot voordat je begint met itereren. Als een nieuw randgeval een werkende flow breekt, kan rollback je een dag besparen die je anders kwijt zou zijn aan het ontwarren van neveneffecten.
Houd scenario's naast het featureverzoek (of in hetzelfde ticket) en behandel ze als versioned requirements. Als prompts evolueren, moet de scenario-set met ze mee evolueren, anders glijdt je definitie van “done” ongemerkt verder weg.
Begin met één zin die het gebruikersdoel en de finishlijn aangeeft.
Breek de prompt vervolgens op in:
Schrijf daarna 1–2 happy paths plus 4–8 randgevallen die echte risico's weerspiegelen (permissies, duplicaten, timeouts, ontbrekende data).
Omdat prompts aannames verbergen. Een prompt kan zeggen “opslaan”, maar niet definiëren of dat conceptueel als concept opslaan vs publiceren bedoeld is, wat er gebeurt bij falen, of wie bevoegd is.
Scenario's dwingen je om de regels vroeg te benoemen, voordat je bugs zoals dubbele inzendingen, permissiemismatches of inconsistente resultaten shipped.
Gebruik Given–When–Then wanneer de feature state heeft en interactief is.
Gebruik een eenvoudige input/output-tabel wanneer je veel vergelijkbare regelchecks hebt.
Kies één formaat voor een maand en standaardiseer het (zelfde tijd, hetzelfde detailniveau). Het beste formaat is het formaat dat je team daadwerkelijk zal blijven gebruiken.
Een goed scenario is:
Het is “klaar” wanneer iedereen het kan draaien en het eens is over de uitkomst zonder discussie.
Richt je op observeerbaar gedrag:
Vermijd implementatiedetails zoals databasetabellen, API-responscodes, achtergrondjobs of frameworks. Die details veranderen vaak en bewijzen niet dat de gebruiker het resultaat kreeg dat hij nodig heeft.
Schrijf het saaiste, normale pad waar alles goed gaat:
Controleer daarna vier dingen: juiste scherm/state, duidelijke succesmelding, data is opgeslagen en de gebruiker kan doorgaan naar de volgende logische actie.
Kies randgevallen op basis van risico en frequentie:
Streef naar , niet naar alle mogelijke variaties.
Doe het veilig en duidelijk:
Een foutscenario moet aantonen dat het systeem geen data corrumpeert of de gebruiker misleidt.
Behandel Koder.ai-output als elke andere app: test wat de gebruiker ervaart, niet hoe de code is gegenereerd.
Praktische aanpak:
Bewaar ze waar het werk al gebeurt en houd één bron van waarheid:
Als je Koder.ai gebruikt, houd scenario's in Planning Mode zodat ze gekoppeld blijven aan de buildgeschiedenis. Het belangrijkste: eis scenario's voordat ontwikkeling als gestart wordt beschouwd.
