AI Testing

Wat is AI Testing?

AI testing dekt twee verwante praktijken: AI-modellen gebruiken om softwaretests te genereren, draaien, en onderhouden, en AI-systemen zelf testen, wier outputs variëren van run tot run en zich verzetten tegen traditionele pass-fail-assertions. Beide mikken op hetzelfde doel, defecten vangen voordat gebruikers dat doen, maar elk vergt andere technieken omdat deterministische en probabilistische software op verschillende manieren falen.

De belangrijkste punten

• De term heeft twee betekenissen in de praktijk: AI die tests schrijft en onderhoudt voor je software, en de discipline van AI-aangedreven features verifiëren, wat meestal LLM evals betekent.
• AI-gegenereerde tests zijn goedkoop om te produceren en duur om te vertrouwen. Een suite geschreven vanuit de implementatie zal bereidwillig de bugs vastleggen die die implementatie bevat.
• Het meest waardevolle gebruik is testonderhoud, suites groen houden door refactors en brozen assertions bijwerken, want dat is het sloofwerk dat mensen vermijden.
• AI-features testen vereist outputs scoren tegen criteria, geen exacte strings toetsen, want dezelfde input kan legitiem verschillende geldige antwoorden opleveren.

Hoe het werkt

Aan de testschrijfkant leest een AI-coding-agent de code onder test, of beter, de specificatie ervoor, en produceert unittests, integratietests, of end-to-end-scripts. Gegeven een falende build kan dezelfde agent de foutoutput lezen, een gebroken test onderscheiden van gebroken code, en repareren wat daadwerkelijk fout is. Sommige teams laten agents tegen de applicatie zelf draaien: een browseragent klikt door gebruikersflows, probeert misvormde inputs, en rapporteert wat breekt, wat verkennend testen op machinesnelheid is. Enterprises bewogen hier vroeg op: in GitHub's 2024-onderzoek onder 2.000 enterprise-developers over vier landen zei meer dan 98% dat hun organisaties hadden geëxperimenteerd met AI voor het genereren van testcases, en gebruikte 92% van de Amerikaanse respondenten het minstens soms [1].

De kritieke ontwerpbeslissing is waaruit de tests gegenereerd worden. Tests afgeleid van een spec met acceptatiecriteria verifiëren bedoeld gedrag. Tests afgeleid van alleen de broncode verifiëren alleen dat de code blijft doen wat hij nu doet, wat nuttig is als regressienet tijdens refactoringwerk maar niets zegt over correctheid. Volwassen teams behandelen gegenereerde tests als elke andere agentoutput: ze gaan door AI code review voordat iemand erop vertrouwt.

AI-systemen testen keert het probleem om. Een feature gedragen door een taalmodel kan niet getoetst worden met expect(output).toBe(...) omdat outputs niet-deterministisch zijn. In plaats daarvan bouwen teams evalsuites: vaste inputsets, beoordeelde outputs, scoring per regels, gelijkenismetingen, of een judge-model, met drempels bedraad in CI zodat een prompt- of modelwijziging die kwaliteit verlaagt, de build laat falen.

Voorbeeld

Een team erft een betalingsservice met 12 procent testdekking. Een engineer schrijft een kort briefje per module dat het beoogde gedrag beschrijft, inclusief randgevallen zoals gedeeltelijke terugbetalingen en valuta-afronding, en laat dan een agent tests genereren vanuit de briefjes in plaats van de code. De eerste run brengt drie echte bugs naar boven waar de implementatie het briefje tegenspreekt, precies omdat de tests niet afgeleid waren van de implementatie. De engineer reviewt de gegenereerde suite, verwijdert een handvol tests die incidentele details toetsen, en mergt. Dekking landt op 78 procent, en twee van de drie bugs blijken live in productie te staan.

Veelvoorkomende misvattingen

De veelgemaakte fout is AI-gegenereerde dekkingscijfers lezen als kwaliteit. Een agent kan een module op een middag naar 95 procent dekking brengen, maar als de tests afgeleid waren van de implementatie, is elk bestaand defect nu verankerd als verwacht gedrag, en de suite zal actief weerstand bieden tegen de fix. Dekking meet welke regels draaiden, en niets over of de assertions intentie coderen. Een kleinere suite gegenereerd vanuit een geschreven spec is meer waard dan een grote gegenereerd vanuit de code.

AI-unittesten

AI-unittesten is de smalste en meest geadopteerde plak van deze praktijk: een model richten op één functie of klasse en om unittests vragen. Individuele gewoontes lopen echter achter op de enterprise-experimenten: in het Stack Overflow Developer Survey van 2025 zei 17,9% van de developers AI meestal te gebruiken voor het schrijven van testcode en gebruikt nog eens 27,5% het gedeeltelijk, terwijl 44,1% helemaal geen plannen heeft om AI voor testen te adopteren [2]. Het werkt goed omdat het bereik klein genoeg is om netjes in een contextvenster te passen en de feedbacklus direct is, de tests compileren en slagen ofwel niet. De gewoontes die het nuttig maken, dragen over van de bredere discipline: formuleer het beoogde gedrag in de prompt in plaats van het model te laten afleiden, vraag expliciet om randgevallen en faalpaden, en lees de assertions voordat je ze committeert. Behandel de output als een concept geschreven door een snelle junior die je gebruikers nooit heeft ontmoet.

FAQ

Kan AI QA-engineers volledig vervangen? Nee. Agents excelleren in gevallen genereren, suites onderhouden, en brute-force-verkenning, maar beslissen wat ertoe doet om te testen, welk risiconiveau acceptabel is, en of vreemd gedrag een bug of een feature is, blijft menselijk oordeel. QA-werk verschuift naar teststrategie ontwerpen en agentoutput reviewen.

Hoe test je niet-deterministische AI-features? Met evals in plaats van exacte assertions: een vaste dataset van inputs, een scoringmethode (regels, gelijkenis, of een LLM-judge), en een drempel afgedwongen in CI. Je meet de verdeling van kwaliteit in plaats van één juist antwoord te toetsen.

Moeten AI-gegenereerde tests gereviewd worden zoals productiecode? Ja, en aantoonbaar zorgvuldiger, want een foute test creëert vals vertrouwen dat de sessie overleeft die hem schreef. Review de assertions op intentie, niet alleen de code op stijl.

Bronnen

1. GitHub. "Meer dan 98% van de ondervraagde enterprise-organisaties had geëxperimenteerd met AI voor het genereren van testcases; 92% van de Amerikaanse respondenten gebruikte het minstens soms." https://github.blog/news-insights/research/survey-ai-wave-grows/. Geraadpleegd augustus 2026.
2. Stack Overflow Developer Survey. "17,9% van de developers gebruikt AI meestal voor het schrijven van testcode, 27,5% gebruikt het gedeeltelijk, en 44,1% heeft geen plannen om AI voor testen te adopteren." https://survey.stackoverflow.co/2025/ai. Geraadpleegd augustus 2026.