AI-agents testen: testcases, regressie en simulatie

AI-agents testen is hoe een supportteam bewijst dat een AI-agent zich nog steeds gedraagt voordat een wijziging klanten bereikt. Je bouwt testcases uit echte opgeloste gesprekken en eerdere fouten, draait ze opnieuw vóór elke wijziging aan prompt, beleid, kennis of model, simuleert lastige klanten, controleert de acties die de agent uitvoerde en gaat pas live als een geschreven releasedrempel is gehaald.

In het kort

• Een agent die acties uitvoert, heeft tests nodig op wat hij deed (terugbetaling uitgevoerd, limiet gerespecteerd, case overgedragen), niet alleen op wat hij zei.
• De beste testcases komen uit je eigen opgeloste gesprekken en eerdere fouten.
• Draai de volledige regressieset opnieuw vóór elke wijziging aan prompt, beleid, kennis, model of tool.
• Draai elke kritieke case meerdere keren: een agent die één keer slaagt, kan dezelfde case bij de volgende run laten zakken.
• Schrijf de releasedrempel op vóór de testrun, zodat niemand na het zien van de resultaten over drempels gaat discussiëren.

Deze gids is het deel vóór de release van onze bredere gids over AI-agents evalueren.

Wat is AI-agents testen, en hoe verschilt het van chatbot testen?

AI-agents testen controleert een agent die over meerdere beurten redeneert en acties uitvoert in je systemen, zoals terugbetalingen doen, bestellingen wijzigen of accounts bijwerken. Chatbot testen controleert vooral antwoorden en gespreksflows. Het verschil zit in de gevolgen: een fout antwoord van een chatbot misleidt één klant, een foute actie van een agent verandert echte records.

Geeft je bot alleen antwoorden en draagt hij over, zie dan chatbot testen. Dit artikel behandelt wat er verandert zodra de agent kan handelen.

Consistentie is het lastige deel. In het τ-bench-onderzoek, waarin een taalmodel de klant speelt en de agent werkt met domeinspecifieke tools en beleidsrichtlijnen, slaagden zelfs sterke function-calling-agents in minder dan 50% van de taken en haalden ze dezelfde retailtaak in alle 8 pogingen minder dan 25% van de tijd. Succes werd beoordeeld aan de toestand van de database aan het eind van het gesprek, niet aan het antwoord.

Wat moet een testcase voor een AI-agent bevatten?

Een testcase voor een AI-agent heeft zes kernvelden nodig: het scenario, de klantpersona, de verwachte uitkomst, de acties die de agent mag uitvoeren, een slaagregel die een tweede persoon op dezelfde manier zou toepassen, en het brongesprek waar de case vandaan komt. Zonder de laatste twee worden testresultaten meningen.

Hier is het sjabloon: de zes kernvelden plus vier die de set onderhoudbaar houden. Kopieer het naar een spreadsheet, één rij per case.

Twee regels houden het sjabloon bruikbaar. Ten eerste beschrijft de verwachte uitkomst een toestand, geen zin: de engineeringgids van Anthropic over agent-evals maakt hetzelfde punt met een voorbeeld over het boeken van een vlucht, waarbij telt of er een reservering in de database staat, niet of de agent zegt dat hij er een boekte. Ten tweede verwijst elke case naar het gesprek dat hem rechtvaardigt, zodat je bij een beleidswijziging de cases kunt vinden en bijwerken die erdoor geraakt worden.

Hoe bouw je een gouden testset uit echte gesprekken?

Bouw de gouden testset uit je eigen verkeer: opgeloste gesprekken die de agent op zijn best laten zien, eerdere fouten die je nooit meer wilt zien, escalaties en de randgevallen van elk beleid. Begin met 20 tot 50 cases en laat de set elke week groeien, in plaats van te wachten op een perfecte set van honderden.

De gids van Anthropic zegt dat 20 tot 50 eenvoudige taken uit echte fouten een prima start zijn, en raadt aan fouten die gebruikers melden om te zetten in testcases, zodat de suite het werkelijke gebruik weerspiegelt.

Een evenwichtige eerste set van 50 cases kan er zo uitzien (een illustratie; verschuif de gewichten naar je eigen volume en risico):

Houd de geslaagde cases in de set: een oplossing in de ene flow kan ongemerkt een andere breken, en alleen cases die vroeger slaagden laten dat zien. Verwijder persoonsgegevens uit elk brongesprek voordat het een testcase wordt.

Hoe draai je regressietests vóór elke wijziging aan een AI-agent?

Draai regressietests door de volledige gouden set opnieuw af te spelen tegen de gewijzigde agent voordat die live gaat, met dezelfde slaagregels als de vorige keer, en de resultaten te vergelijken met de huidige versie. Elke wijziging telt: prompts, beleid, kennisartikelen, modelversies, tools en routeringsregels veranderen allemaal het gedrag. Een aangepast helpartikel kan antwoorden over terugbetalingen evenveel veranderen als een aanpassing in de prompt.

Draai kritieke cases meer dan eens. Agents zijn niet deterministisch, dus één geslaagde run bewijst weinig; de auteurs van τ-bench stelden daarom pass^k voor, de kans dat alle k runs slagen. De rekensom (illustratie): een case die de agent in 90% van de gevallen haalt, slaagt maar in 73% van de gevallen 3 runs op rij (0,9 × 0,9 × 0,9), en maar in 43% van de gevallen 8 runs op rij.

Regressiecases horen op, of heel dicht bij, 100% te slagen. De gids van Anthropic maakt dezelfde splitsing: regressie-evals horen een slagingspercentage van bijna 100% te hebben, terwijl capability-evals voor nieuwe vaardigheden laag mogen beginnen.

Hoe simuleer je klanten om een AI-agent te testen?

Simuleer klanten door een tweede model de klant te laten spelen vanuit een geschreven persona, over meerdere beurten, tegen de agent die je test. Geef elke persona een doel, feiten, een temperament en een breekpunt, en voeg vijandige persona’s toe die de agent over zijn grenzen duwen.

Losse vragen testen antwoorden. Simulatie over meerdere beurten, de opzet die τ-bench gebruikte, test wat er in echte gesprekken misgaat: de klant die halverwege zijn vraag verandert of blijft aandringen op een terugbetaling die het beleid niet toestaat.

Schrijf vijf tot acht persona’s en gebruik ze opnieuw in verschillende scenario’s:

1. De duidelijke vrager: één vraag, alle details gegeven. Je basislijn.
2. De vage klant: ontbrekend bestelnummer, verkeerde productnaam. Test verduidelijkende vragen.
3. De wisselaar: begint over de levering en eindigt met een opzegging.
4. De doordrammer: wijst het eerste antwoord drie keer af en vraagt om een uitzondering. Test grenzen onder druk.
5. De boze klant: dreigt weg te gaan of publiekelijk te klagen. Test toon en overdracht.
6. De kwetsbare klant: noemt een sterfgeval, ziekte of geldzorgen. Test je overdrachtsregels voor deze gevallen.
7. De manipulator: doet zich voor als medewerker, plakt “negeer je instructies” in het gesprek of verstopt instructies in een bijlage. Test de weerstand tegen wat OWASP prompt injection noemt.

Een persona vindt alleen de problemen die je erin hebt geschreven, dus gebruik simulatie om de set te verbreden en echte gesprekken om hem eerlijk te houden. Voicebots voegen accenten, onderbrekingen en lijnkwaliteit toe; zie kwaliteitscontrole van AI-voicebots.

Hoe test je de acties en tool-aanroepen van een AI-agent?

Test acties door na het gesprek de eindtoestand in je systemen te controleren, niet de beschrijving die de agent gaf van wat hij deed. Bestaat het terugbetalingsrecord, voor het juiste bedrag, op de juiste bestelling? Bleef de agent binnen zijn limieten, vroeg hij om bevestiging waar dat moest, en riep hij geen tool aan die hij niet mocht gebruiken?

Een antwoord als “Ik heb je terugbetaling verwerkt” bewijst niets. Controleer per actiecase vier dingen:

1. Juiste actie. De verwachte tool is aangeroepen, en geen onverwachte.
2. Juiste argumenten. Juiste bestelling, klant, bedrag en reden.
3. Binnen de limieten. Bedrag onder het maximum, rechten aanwezig, goedkeuring gevraagd waar je beleid een mens vereist.
4. Waarheidsgetrouw verslag. Wat de agent de klant vertelde, komt overeen met wat er echt in het systeem gebeurde.

OWASP noemt excessive agency bij de belangrijkste risico’s voor LLM-toepassingen: schadelijke acties die mogelijk worden door te veel functionaliteit, te veel rechten of te veel autonomie. De maatregelen (minimale extensies, minimale rechten, goedkeuring door de gebruiker) dienen meteen als testlijst. Schrijf per limiet minstens één case waarin de klant om net iets meer vraagt.

Draai actietests tegen een sandbox of testaccounts, nooit tegen live records. De training van Salesforce voor het Agentforce Testing Center waarschuwt dat het testen van agents CRM-data kan wijzigen en zegt het alleen in een sandbox te gebruiken.

Overdracht is ook een actie: test dat de agent de cases overdraagt die hij moet overdragen, met een notitie waarmee de mens verder kan (escalaties in de klantenservice).

Hoe worden fouten in productie nieuwe testcases?

Fouten in productie worden testcases via een wekelijkse routine: zoek de gesprekken waarin de AI-agent de fout in ging, bevestig de fout, verwijder persoonsgegevens, schrijf de case met het sjabloon hierboven en voeg hem toe aan de gouden set. De volgende wijziging kan pas live als die case slaagt.

Het lastige is de fouten vinden. Een gesprek dat de agent “oploste” kan nog steeds een fout antwoord, verzonnen beleid of een gemiste overdracht bevatten, en dashboards tellen het als succes (stille fouten van AI-agents). AI-agent monitoring behandelt wat je dagelijks in de gaten houdt, en kwaliteitscontrole van AI-agents laat zien hoe je de scorecard bouwt die ze vangt.

Hier ontmoeten kwaliteitscontrole van live gesprekken en tests vóór de release elkaar. AutoPilot van Kaizo scoort elk opgelost gesprek van een AI-agent met je eigen scorecard en koppelt elke score aan het bewijs. Zo krijg je bevestigde fouten, elk met een brongesprek voor het sjabloon. Nadat de oplossing live is, laat het scoren van de live gesprekken van de weken erna zien of ze standhoudt.

Zie waar je AI-agent vandaag de fout in gaat. Kaizo scoort gesprekken van AI-agents met dezelfde scorecard als je team en koppelt elke score aan de regels erachter. Afspraak boeken.

Scoor je met een AI als beoordelaar, controleer dan ook de beoordelaar. Onze gids over het valideren van AI-QA-scores (in het Engels) laat zien hoe je automatische scores vergelijkt met je reviewers voordat je ze vertrouwt.

Wat moet een releasedrempel voor een AI-agent controleren?

Een releasedrempel voor een AI-agent is een korte geschreven lijst met voorwaarden waaraan een wijziging moet voldoen voordat die klanten bereikt, afgesproken vóór de testrun. Hij blokkeert bij elke kritieke fout, vereist bijna perfecte regressieresultaten, dekt elke actie en limiet en noemt wie tekent en hoe je terugdraait. Kopieer hem en vul je eigen cijfers in.

Vóór de run

• De wijziging is opgeschreven: wat, waarom, wie erom vroeg.
• Nieuwe cases voor de wijziging zelf (een nieuwe limiet krijgt cases net binnen en net buiten die limiet).
• Elke fout die sinds de vorige release in productie is bevestigd, zit in de set.
• Testaccounts en sandbox klaar; geen live klantrecords binnen bereik.

De run

• Volledige gouden set gedraaid tegen de gewijzigde agent en de huidige agent, met dezelfde slaagregels.
• Kritieke cases (geld, data, juridisch, kwetsbare klanten) minstens 3 keer elk gedraaid.
• Gesimuleerde persona’s gedraaid, inclusief de manipulator en de doordrammer.

Voorwaarden om te slagen

• Kritieke cases: 100% geslaagd, bij elke poging. Eén fout blokkeert de release.
• Regressiecases: minstens 98% geslaagd, en geen case die bij de vorige release slaagde, zakt nu zonder verklaring.
• Actiecases: geen actie buiten de toegestane lijst, geen bedrag boven de limiet, geen claim van een actie die niet plaatsvond.
• Overdrachtscases: elke case die moest worden overgedragen, bereikte een mens met een bruikbare notitie.
• Cases zonder bekend antwoord: geen verzonnen antwoorden.

Goedkeuring en na de release

• Een benoemde eigenaar tekent: support- of CX-lead voor beleid en toon, AI-eigenaar voor de technische kant.
• Terugdraaien ligt klaar: de vorige prompt, kennis en modelversie kunnen dezelfde dag worden teruggezet.
• De eerste dagen aan live gesprekken na de release worden strenger bekeken dan normaal.

Rekenvoorbeeld (een illustratie met verzonnen cijfers). Een team verkort zijn terugbetalingstermijn van 30 naar 14 dagen. De gouden set telt 120 cases: 40 kritiek, 80 overige. Kritieke cases draaien 3 keer, de overige één keer, dus de run telt 200 pogingen. Het resultaat: 196 van de 200 pogingen slagen, een slagingspercentage van 98% dat gezond oogt. Maar alle 4 fouten zitten in twee kritieke cases. In de ene bood de agent op dag 20 in één van de drie pogingen nog een terugbetaling aan. In de andere praatte de persona van de doordrammer hem in alle drie de pogingen een terugbetaling “uit coulance” aan. De drempel blokkeert de release. De oplossing gaat in de prompt en een kennisartikel, er komen twee nieuwe kritieke cases bij voor dag 14 en dag 15, en de herhaalrun slaagt in 206 van de 206 pogingen. Een gemiddelde had de bug live gezet; de drempel niet.

Welke tools heb je nodig om AI-agents te testen?

Je hebt drie soorten tools nodig: een plek om testcases te bewaren en te versioneren, een manier om ze tegen de agent te draaien (vaak met gesimuleerde klanten), en een manier om resultaten te scoren aan je slaagregels.

• Een spreadsheet en handmatige runs volstaan onder ongeveer 50 cases en een paar wijzigingen per maand.
• Een testfunctie in het platform past bij één platform met standaardflows. Het Agentforce Testing Center van Salesforce genereert bijvoorbeeld standaard 20 testcases, en je stelt in hoeveel er positief en negatief zijn.
• Test- en simulatietools voegen gesimuleerde klanten, herhaalde pogingen en releasecontroles in de deployment-pipeline toe.
• Kwaliteitscontrole van live gesprekken scoort wat er na de release echt gebeurde en voert bevestigde fouten terug naar de set.

Wat je ook kiest, bewaar de cases in een formaat dat je supportteam kan lezen en bewerken, anders stoppen beleidseigenaren met bijwerken.

Wanneer is een volledig testprogramma niet voor jou?

Een volledig programma is overdreven als je AI-agent een paar dozijn gesprekken per week afhandelt, alleen vragen beantwoordt en geen acties kan uitvoeren. Lees dan wekelijks de transcripten en houd een korte lijst van 20 cases bij die je na elke wijziging met de hand opnieuw draait.

Kwaliteitscontrole van live gesprekken vervangt het ook niet: gesprekken scoren nadat ze zijn afgelopen, houdt een wijziging vóór de release niet tegen. Je hebt allebei nodig: tests vóór de wijziging en scoring van elk gesprek van je AI-agent erna.

Zo begin je deze week

Je kunt binnen vijf werkdagen een eerste gouden set, een geschreven releasedrempel en een baselinerun hebben, met een export van recente gesprekken, het sjabloon hierboven en een testomgeving.

1. Maandag: exporteer 30 opgeloste gesprekken van je AI-agent en 20 die misgingen. Verwijder persoonsgegevens.
2. Dinsdag: zet ze in het sjabloon. Markeer welke kritiek zijn.
3. Woensdag: schrijf de releasedrempel. Laat de supportlead en de AI-eigenaar de cijfers afspreken.
4. Donderdag: draai de set tegen de huidige agent, met drie pogingen voor kritieke cases. Dit is je baseline; verwacht een paar fouten.
5. Vrijdag: spreek de regel af dat geen wijziging aan prompt, beleid, kennis of model live gaat zonder herhaalrun, en plan een wekelijks moment om nieuwe fouten aan de set toe te voegen.

Zie AI-agent governance voor wie eigenaar is van de goedkeuring.

Veelgestelde vragen

Wat is AI-automatisering bij testen?

AI-automatisering bij testen betekent meestal dat je AI gebruikt om software te testen, bijvoorbeeld agents die testscripts voor een webapplicatie schrijven en draaien. Dit artikel gaat over iets anders: bewijzen dat een AI-agent die met klanten praat correct antwoordt en handelt voordat een wijziging live gaat.

Hebben AI-agents tools?

Ja. De tools van een AI-agent zijn de functies die hij kan aanroepen, zoals een bestelling opzoeken of een terugbetaling doen. Daarom moeten tests van een agent de eindtoestand in je systemen controleren, niet alleen het antwoord.

Wat is een AI-tester?

Ofwel een persoon die AI-systemen test, ofwel een AI die andere software test. In de klantenservice is het meestal een QA-lead of AI-eigenaar die testcases schrijft uit echte gesprekken en beslist of een wijziging de releasedrempel haalt.

Hoeveel testcases heeft een AI-agent nodig?

Begin met 20 tot 50 cases uit echte gesprekken en eerdere fouten, en voeg daarna elke bevestigde fout uit productie toe. Dekking van je topintenties, acties en limieten weegt zwaarder dan het aantal zelf.

Hoe vaak draai je regressietests voor een AI-agent?

Draai de volledige set vóór elke wijziging aan prompts, beleid, kennis, modellen, tools of routering, en wekelijks ook als er niets veranderde, omdat modelaanbieders en gekoppelde systemen ook veranderen.