Een user story schrijven en er binnen enkele minuten uitvoerbare testcases uit krijgen. Dat is vandaag geen toekomstmuziek meer.
AI kan verrassend goede eerste versies genereren. De vraag is niet meer óf het werkt, maar hoe je van een AI-gegenereerde eerste versie een betrouwbare geautomatiseerde test maakt.
Hoe het proces verloopt
van user story naar test
◉
AI analyseert
scenario's & criteria
</>
Gherkin of testcode
gegenereerd
◎
Menselijke review
verplichte check
✓
Geautomatiseerde test
definitief
Sommige tools werken met Cucumber-achtige taal als tussenstap: je beschrijft een scenario in gewone taal, en de AI vertaalt dat naar automatiseringscode. Andere genereren rechtstreeks Playwright- of Selenium-code op basis van een beschrijving. Beide aanpakken verlagen de drempel: ook wie niet dagelijks code schrijft, kan een eerste testopzet maken.
AI kan een testcase schrijven. Ze kan niet beoordelen of die testcase het juiste risico afdekt.
Waar het goed werkt
- Happy-path-scenario's: standaard gebruikersflows zijn voorspelbaar en lijken sterk op voorbeelden waarop AI-modellen getraind zijn.
- Nieuwe feature: een eerste versie genereren kost seconden en voorkomt repetitief werk.
- Migraties: AI kan bestaande Selenium-tests vaak verrassend goed omzetten naar Playwright of andere frameworks.
Waar menselijke review onmisbaar blijft
Edge cases en negatieve scenario's
AI-gegenereerde tests neigen naar het voor de hand liggende pad. De scenario's die écht bugs vangen (grenswaarden, foutafhandeling, ongebruikelijke combinaties) vragen nog steeds domeinkennis.
Assertions die te zwak zijn
Een login-test die alleen controleert dat er geen foutmelding verschijnt, bewijst nog niet dat de gebruiker daadwerkelijk correct aangemeld is.
Bedrijfslogica die de AI niet kent
Een model kent je specifieke bedrijfsregels niet, tenzij je die expliciet meegeeft. Zonder context genereert het generieke tests die de eigenheid van je systeem missen.
De teams die hier het meeste rendement uit halen, gebruiken AI niet om testers te vervangen. Ze gebruiken AI om repetitief werk te versnellen, zodat testers zich kunnen richten op de scenario's waar ervaring, context en kritisch denken het verschil maken.
Een voorbeeld uit de praktijk
Bij een klant met een wachtwoord-resetflow leverde een AI-tool op basis van de user story "Als gebruiker wil ik mijn wachtwoord kunnen resetten" binnen twee minuten een werkende Playwright-test op. De test was functioneel correct en volledig groen.
// AI-gegenereerd: enkel het happy path
1. vraag reset-link aan via e-mailadres
2. open de link uit de e-mail
3. vul een nieuw wachtwoord in
4. log in met het nieuwe wachtwoord
// Ontbrak, en kwam pas bij review naar boven:
// - is het oude wachtwoord na reset nog geldig?
// - wat gebeurt er met een verlopen reset-link?
// - is er een limiet op het aantal reset-aanvragen per uur?
Geen van die drie scenario's staat in een gemiddelde user story, maar elk ervan is precies het soort fout dat een aanvaller of een gefrustreerde gebruiker als eerste tegenkomt.
Een reviewchecklist die we standaard toepassen
- Tel de negatieve paden. Staat er voor elk happy-path-scenario minstens één foutscenario tegenover? Zo niet, is de dekking eenzijdig.
- Controleer de sterkte van elke assertion. "Geen foutmelding zichtbaar" is geen bewijs van succes; controleer het daadwerkelijke resultaat (redirect, databasestatus, ontvangen e-mail).
- Herken hard-coded wachttijden. AI-gegenereerde tests grijpen opvallend vaak naar een vaste sleep() in plaats van een expliciete wachtconditie: een directe bron van flakiness die pas weken later aan het licht komt.
- Vraag naar de testdata achter het scenario. Genereert de test zijn eigen, unieke testgebruiker, of hergebruikt hij een gedeeld account dat bij parallelle runs conflicten geeft?
// Sneller starten, grondig blijven
Benieuwd hoe AI-testgeneratie past in jouw workflow?
We tonen concreet wat werkt voor jouw stack, en waar menselijke review het verschil blijft maken.
Plan een gesprek