AI-agents evalueren is hoe een supportteam aantoont dat zijn AI-agent juiste, toegestane en behulpzame antwoorden geeft. Het gebeurt in twee fases: evals voor de lancering, waarin je testgesprekken draait tegen geschreven succescriteria, en evaluatie in productie, waarin je echte klantgesprekken scoort tegen een scorecard. Je hebt beide nodig, plus een gekalibreerde beoordelaar en een benoemde eigenaar.
In het kort
- Evals voor de lancering vertellen je of een wijziging veilig live kan; evaluatie in productie vertelt je wat de AI-agent werkelijk met klanten heeft gedaan.
- Meet juiste oplossing, naleving van beleid, juistheid van acties, kwaliteit van escalaties en toon; behandel containment als context, nooit als kwaliteitsscore.
- Gebruik een LLM-judge voor het volume en menselijke beoordelaars voor kalibratie en gevallen met hoog risico, en controleer hun overeenstemming per criterium.
- Kleine steekproeven missen zeldzame maar dure fouten: bij 40.000 gesprekken per maand heeft een steekproef van 1% een kans van 45% om geen enkel geval te tonen van een fout die 80 klanten treft.
- Geef elke KPI een eigenaar, een drempel en een frequentie; het raamwerk hieronder is een vertrekpunt dat je kunt kopiëren.
Deze gids is voor de supportmanager die verantwoordelijk is voor de agent zodra die met klanten praat, niet voor de engineers die hem bouwen. Voor de basis lees je kwaliteitscontrole van AI-agents en chatbots; twijfel je nog hoe ver je wilt automatiseren, begin dan met agentische klantenservice.
Wat is het evalueren van AI-agents in de klantenservice?
Het evalueren van AI-agents in de klantenservice is het herhaalbare proces waarin je de gesprekken van een AI-agent toetst aan geschreven succescriteria: was het antwoord juist, was het toegestaan volgens het beleid, gebeurde de beloofde actie echt, droeg de agent het gesprek over wanneer dat moest, en was de toon goed. Het draait voor de lancering op testcases en na de lancering op echte gesprekken.
Je AI-team gebruikt deze termen uit handleidingen voor ontwikkelaars:
| Term | Wat het betekent | Voorbeeld uit de support |
|---|---|---|
| Task of testcase | Eén scenario met vastgelegde input en succescriteria | “Klant vraagt om terugbetaling van een bestelling die 40 dagen geleden is geleverd” |
| Grader | De logica die één aspect van het resultaat scoort | “Weigerde de agent de terugbetaling volgens het beleid van 30 dagen?” |
| Transcript | Het volledige verslag van een run, inclusief de acties van de agent | De chat plus het API-verzoek voor de terugbetaling en het antwoord daarop |
| Outcome | De eindtoestand in je systemen | Staat er echt een terugbetaling in het ordersysteem? |
De laatste rij weegt voor support het zwaarst. Een transcript waarin de agent zegt “je terugbetaling is onderweg” is niet hetzelfde als een terugbetaling in het systeem. Praktijkmensen die supportagents draaien beschrijven precies deze fout: de agent meldt een actie als uitgevoerd terwijl de API-call erachter mislukte.
Wat betekent “Demystifying evals for AI agents” van Anthropic voor supportteams?
Het engineeringartikel Demystifying evals for AI agents (in het Engels) van Anthropic is de gids waar de meeste mensen op naam naar zoeken. Voor supportteams komt het neer op vijf punten: begin klein met echte fouten, controleer uitkomsten en niet alleen woorden, meet consistentie, test beide kanten van elke beslissing, en blijf transcripten lezen.
- Begin met 20 tot 50 echte fouten. Het artikel noemt 20 tot 50 eenvoudige taken uit echte fouten “a great start” (een prima begin) en noemt de supportwachtrij als bron. Je QA-team heeft ze al.
- Beoordeel de uitkomst, niet het verhaal. Het voorbeeld over terugbetalingen in het artikel combineert een controle van de toestand (ticket opgelost, terugbetaling verwerkt), controles op de acties van de agent (identiteit geverifieerd, terugbetaling binnen de limieten) en een LLM-rubric voor empathie en duidelijkheid.
- Meet consistentie met pass^k, de kans dat alle k runs van een taak slagen. Het artikel merkt op dat dit “especially matters for customer-facing agents where users expect reliable behavior every time” (vooral telt voor agents die met klanten praten, waar gebruikers elke keer betrouwbaar gedrag verwachten). Een agent die 75% van de keren slaagt voor een taak, slaagt maar in ongeveer 42% van de gevallen voor alle 3 runs.
- Test beide richtingen. Controleer wanneer de agent moet handelen en wanneer niet. Een testset vol gevallen waarin terugbetaald moet worden, levert een agent op die te vaak terugbetaalt.
- Lees de transcripten. “You won’t know if your graders are working well unless you read the transcripts and grades from many trials.” (Je weet pas of je graders goed werken als je de transcripten en scores van veel runs leest.)
Het artikel noemt monitoring in productie ook reactief: klanten lopen eerder tegen het probleem aan dan jij. Supportteams hebben beide fases nodig.
Evals voor de lancering of evaluatie in productie: wat is het verschil?
Evals voor de lancering draaien je AI-agent op testgesprekken voordat een wijziging live gaat, om een slechte prompt, een slecht model of een slechte kennisupdate tegen te houden. Evaluatie in productie scoort de echte gesprekken die klanten hadden, zodat je fouten vindt die je testset nooit had bedacht. Voor de lancering is het een poort; in productie is het de doorlopende kwaliteitscontrole.
| Evals voor de lancering | Evaluatie in productie | |
|---|---|---|
| Vraag die het beantwoordt | Kan deze wijziging veilig live? | Wat deed de agent deze week met klanten? |
| Input | Testcases, gesimuleerde klanten, opnieuw afgespeelde oude gesprekken | Elk echt gesprek dat de AI-agent afhandelde |
| Wanneer het draait | Voor elke wijziging in prompt, model, tool of content | Doorlopend, zodra gesprekken zijn afgehandeld |
| Typische eigenaar | Eigenaar AI of automatisering | QA-lead, met de CX-manager die de drempels bepaalt |
| Sterkte | Vangt regressies af voordat klanten ze zien | Vangt af waar niemand aan dacht om te testen |
| Blinde vlek | Vindt alleen wat in de testset zit | Vindt problemen pas nadat ze zijn gebeurd |
| Verdieping | AI-agents testen en chatbot testen | AI-agent monitoring en de rest van deze pagina |
De twee fases voeden elkaar: elke fout die je in productie vindt, wordt een nieuwe testcase. Simulatie, waarbij een tweede model de klant speelt, hoort bij de kant voor de lancering; benchmarks zoals τ-bench (in het Engels) gebruiken het voor supporttaken in retail en luchtvaart.
Hoe schrijf je evals voor een AI-agent?
Om evals voor een AI-agent te schrijven, verzamel je 20 tot 50 echte gesprekken waarin de agent of je team het fout deed, schrijf je per gesprek op hoe een juiste uitkomst eruitziet, voeg je gevallen toe waarin weigeren of escaleren de juiste stap is, geef je elk criterium een eigen grader en draai je elke case meerdere keren voor elke wijziging.
Het supportteam bepaalt de inhoud; de AI-kant bouwt het in:
- Haal de cases uit QA. Mislukte of geëscaleerde gesprekken van de laatste 90 dagen, gegroepeerd per intent.
- Schrijf de verwachte uitkomst in één zin. “Weigert de terugbetaling, citeert het beleid van 30 dagen, biedt tegoed aan, escaleert niet.”
- Voeg de spiegelcases toe. Voor elke case “moet weigeren” een case “moet het doen”; voor elke case “moet escaleren” een case waarin escaleren fout zou zijn.
- Splits de criteria. Juistheid, beleid, actie, escalatie en toon krijgen elk hun eigen controle; het artikel van Anthropic raadt één judge per rubricdimensie aan.
- Controleer het systeem, niet de zin. Waar de agent een actie uitvoert, leest de grader het record in het ordersysteem of de helpdesk, niet de bewering van de agent.
- Draai elke case 3 tot 5 keer en tel hem alleen als geslaagd als alle runs slagen. Dat is pass^k in de praktijk.
- Houd twee sets aan. Een regressieset die bijna 100% van de tijd zou moeten slagen, en een moeilijkere capability-set voor de intents die je hierna wilt automatiseren.
De minimale versie, zoals praktijkmensen hem beschrijven, is een paar dozijn echte tickets die misgingen, die je opnieuw draait elke keer dat de prompt verandert. Onze gids over AI-agents testen behandelt testontwerp, regressieruns en simulatie in detail.
Welke KPI’s voor het evalueren van AI-agents tellen in de klantenservice?
De KPI’s die tellen bij het evalueren van AI-agents in de klantenservice zijn juiste oplossing, juistheid van antwoorden, naleving van beleid, juistheid van acties, kwaliteit van escalaties en toon, ondersteund door herhaalcontact en klantfeedback. Containment en deflectie vertellen je alleen dat de klant geen mens heeft bereikt; ze horen in de contextkolom, niet in de kwaliteitsscore.
| KPI | Definitie | Waarom het telt |
|---|---|---|
| Juiste oplossing | Aandeel door AI afgehandelde gesprekken dat als opgelost is gescoord, met een juist antwoord en zonder herhaalcontact binnen 7 dagen | De eerlijke versie van “oplospercentage” |
| Juistheid van antwoorden | Aandeel gesprekken zonder feitelijke fout ten opzichte van je eigen content | Vangt verzonnen beleid, prijzen en stappen af |
| Naleving van beleid | Aandeel gesprekken zonder schending van regels voor terugbetaling, identiteit, transparantie of scope | Eén schending herhaalt zich in elk vergelijkbaar gesprek |
| Juistheid van acties | Aandeel acties dat de agent claimde en dat overeenkomt met het record in het systeem | Vangt “terugbetaling verwerkt” af als de API mislukte |
| Kwaliteit van escalaties | Aandeel overdrachten op de juiste trigger, met overgedragen context; plus het percentage gemiste escalaties | Slechte overdrachten laten de klant opnieuw beginnen |
| Toon | Aandeel gesprekken dat slaagt voor je criteria voor toon en empathie | Juiste maar kille antwoorden kosten nog steeds klanten |
| Containment (context) | Aandeel gesprekken dat nooit bij een mens terechtkwam | Alleen een volume-indicator; telt foute antwoorden als winst |
Combineer de containment rate (in het Engels) met een controle op oplossing, lees de prestaties van een AI-agent meten om afhandeling door AI en door mensen eerlijk te vergelijken, en zet de criteria op een scorecard voor AI-agents.
LLM-as-a-judge of menselijke review: hoe kalibreer je ze?
Gebruik een LLM-judge om elk gesprek te scoren en menselijke beoordelaars om hem te kalibreren en de gevallen met hoog risico op zich te nemen. Kalibreer door twee beoordelaars en de judge blind dezelfde 100 tot 200 gesprekken te laten scoren, meet dan de overeenstemming per criterium apart en verbeter de formulering van het criterium waar judge en mensen het oneens zijn.
LLM-as-a-judge betekent dat een taalmodel een gesprek beoordeelt tegen je geschreven criteria (onze definitie, in het Engels). Het paper Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (in het Engels) vond dat GPT-4 meer dan 80% overeenstemming met menselijke voorkeuren haalde, hetzelfde niveau waarop mensen het met elkaar eens zijn. Het noemt ook de zwakke plekken van de judge: positiebias, voorkeur voor lange antwoorden, voorkeur voor eigen output, en beperkt redeneervermogen.
Een kalibratieroutine die standhoudt:
- Scoor blind. Twee beoordelaars en de judge scoren dezelfde set apart. De beoordelaars worden het eerst eens, en vergelijken daarna met de judge.
- Meet per criterium. Een totaal van 90% kan een tooncriterium van 70% verbergen. Volg voor criteria met voldoende of onvoldoende de recall: hoeveel van de echte beleidsschendingen ving de judge op?
- Laat de judge “onbekend” zeggen. Het artikel van Anthropic raadt aan de judge een uitweg te geven, zodat hij minder scores verzint. Stuur “onbekend” door naar een mens.
- Kalibreer opnieuw na elke wijziging in de scorecard, het model van de judge of de scope van de agent, en minstens maandelijks.
Ons protocol om AI-QA-scores in een week te valideren (in het Engels) maakt hier een dagplan van, met drempels voor overeenstemming.
Hoeveel gesprekken moet je evalueren?
Voor evals voor de lancering volstaan 20 tot 50 echte foutgevallen om te beginnen, oplopend tot een paar honderd naarmate je meer intents automatiseert. Scoor bij evaluatie in productie van een AI-agent elk gesprek als dat kan, want de duurste fouten zijn zeldzaam en zeldzame fouten verstoppen zich in steekproeven. Houd dubbele menselijke scoring op 100 tot 200 gesprekken per maand.
Illustratie (geen klantdata). Een AI-agent handelt 40.000 gesprekken per maand af. Het QA-team beoordeelt een steekproef van 1%: 400 gesprekken.
| Fout | Frequentie | Getroffen klanten per maand | Verwacht in de steekproef van 400 | Kans dat de steekproef er geen toont |
|---|---|---|---|---|
| Verkeerd recht op terugbetaling | 0,5% | 200 | 2 | 13% |
| “Terugbetaling verwerkt” terwijl de API mislukte | 0,2% | 80 | 0,8 | 45% |
De kans dat je er geen ziet, is (1 min de frequentie) tot de macht 400. Zelfs twee opgevangen terugbetalingsfouten lijken op ruis; als je alle 40.000 gesprekken scoort, zie je 200 en 80 gevallen, gegroepeerd per intent.
Drie vuistregels:
- Foutmarge. Een percentage juiste oplossingen van 90%, gemeten op 400 gesprekken, is nauwkeurig tot ongeveer ±3 punten (95% betrouwbaarheid), dus een daling naar 88% valt binnen de ruis. Op 40.000 gesprekken is de marge ongeveer ±0,3 punten.
- Nul fouten is niet nul risico. Zie je geen fouten in n gesprekken, dan kan de echte frequentie nog steeds tot ongeveer 3 gedeeld door n zijn: om een frequentie onder 1% aan te tonen heb je ongeveer 300 foutloze gesprekken nodig, onder 0,1% ongeveer 3.000.
- Kalibratiesets zijn bewust klein. 200 dubbel gescoorde gesprekken met 85% overeenstemming leggen die overeenstemming vast binnen ongeveer ±5 punten: genoeg om een slecht geformuleerd criterium te vinden, niet om beoordelaars te rangschikken.
De rekenkunde staat uitgelegd in ons artikel over statistiek van QA-steekproeven (in het Engels).
Het raamwerk voor het evalueren van AI-agents (kopieer deze tabel)
Dit raamwerk zet op een rij wat je evalueert, de methode, de KPI, een voorbeelddrempel, de eigenaar en de frequentie voor een AI-agent in de klantenservice. De drempels zijn voorbeelden om over te discussiëren, geen benchmarks uit de sector: bepaal de jouwe op basis van je eigen baseline en van wat één fout je kost.
| Wat je evalueert | Methode | KPI | Voorbeelddrempel | Eigenaar | Frequentie |
|---|---|---|---|---|---|
| Juistheid van antwoorden | LLM-judge met toegang tot je kennisbank; steekproefsgewijze controles door mensen | Aandeel gesprekken zonder feitelijke fout | 98% of hoger; elk nieuw type fout binnen een week herleid tot de bron | QA-lead met de eigenaar van de kennis | Elk gesprek gescoord; wekelijkse review |
| Naleving van beleid | Regelcontroles op acties plus een LLM-judge op formulering | Percentage schendingen, gesplitst in kritiek en klein | Nul kritieke schendingen op de regressieset; elke schending in productie beoordeeld | Eigenaar beleid of compliance | Elk gesprek; alert op dezelfde dag bij kritieke schendingen |
| Juistheid van acties | Vergelijk de bewering van de agent met het record in het systeem | Percentage verschillen tussen geclaimde en echte acties | Nul verschillen voor de lancering; elk verschil in productie beoordeeld | Eigenaar AI of automatisering | Voor elke wijziging; dagelijks in productie |
| Juiste oplossing | LLM-judge plus herhaalcontact binnen 7 dagen | Aandeel door AI afgehandelde gesprekken dat juist is opgelost | Bepaald op basis van de baseline van je eerste maand; onderzoek een daling van 3 punten of meer | CX-manager | Wekelijks |
| Kwaliteit van escalaties | Scorecardcriteria: juiste trigger, context overgedragen, geen lus | Percentage gemiste escalaties; aandeel overdrachten met volledige context | Alle testcases “moet escaleren” slagen voor de lancering; gemiste escalaties live onder 1% | QA-lead met de eigenaar van de routering | Wekelijks |
| Toon en empathie | LLM-judge per criterium, gekalibreerd door beoordelaars | Aandeel dat slaagt voor de tooncriteria | 95% of hoger, na kalibratie | QA-lead | Elk gesprek; maandelijkse kalibratie |
| Consistentie | Herhaalde runs van de kritieke testset | pass^k met k = 5 | 90% of hoger op kritieke taken | Eigenaar AI of automatisering | Voor elke wijziging in prompt, model, tool of content |
| Nauwkeurigheid van de judge | Blinde dubbele scoring door twee beoordelaars | Overeenstemming per criterium; recall op kritieke onvoldoendes | 85% overeenstemming of hoger per criterium; 90% recall op kritieke onvoldoendes | QA-lead | Maandelijks, en na elke wijziging in scorecard of model |
| Uitkomst voor de klant | CSAT op door AI afgehandelde gesprekken, herhaalcontact, afhaken | Trend ten opzichte van je baseline | Geen daling twee weken op rij | CX-manager | Wekelijks; maandelijks in de evaluatie van de prestaties van de AI-agent |
Waarom de drempel voor consistentie streng is: een taak die in 98% van de losse runs slaagt, slaagt in ongeveer 90% van de gevallen voor alle 5 runs, en een taak met 95% maar in ongeveer 77%. Klanten krijgen welke run er toevallig gebeurt.
Wie moet eigenaar zijn van het evalueren van AI-agents?
Het evalueren van AI-agents heeft drie eigenaren nodig: de eigenaar AI of automatisering draait de evals voor de lancering en verbetert prompts en tools, de QA-lead draait de scoring in productie en de kalibratie van de judge, en de CX-manager bepaalt de drempels en beslist of de agent uitbreidt, gelijk blijft of wordt ingeperkt. Eigenaren van kennis en beleid verbeteren de content waar de scores naar wijzen.
De gebruikelijke fout is evaluatie die alleen ligt bij het team dat de agent bouwt: bouwers meten wat zij kunnen veranderen, terwijl supportmanagers moeten zien wat klanten kregen. Leg de cijfers uit productie bij iemand van support; het raamwerk hierboven noemt een eigenaar per KPI. Evaluatie is één onderdeel van een breder model voor toezicht, dat we behandelen in onze gids over AI-agent governance.
Welke tools gebruiken supportteams om AI-agents te evalueren?
Supportteams gebruiken vier soorten tools om AI-agents te evalueren: eval- en observabilityplatformen voor ontwikkelaars voor tests en traces voor de lancering, simulatietools die de klant spelen, de analytics die in het agentplatform zijn ingebouwd, en QA-platformen voor gesprekken die echte gesprekken op een scorecard scoren. De meeste enterpriseteams eindigen met één tool per fase.
| Type tool | Voorbeelden in de markt | Beantwoordt | Beperkingen voor een supportmanager |
|---|---|---|---|
| Eval en observability voor ontwikkelaars | LangSmith, Langfuse, Arize Phoenix, Braintrust, DeepEval | Brak deze wijziging een test? Waar in de trace ging het mis? | Gebouwd voor engineers; scores sluiten zelden aan op je supportscorecard |
| Simulatietests | Gespecialiseerde tools voor simulatie en testgesprekken | Hoe gaat de agent om met honderden gescripte klanten? | Zo goed als de scenario’s; geen echte klanten |
| Analytics van het agentplatform | Rapportage in Intercom Fin, Zendesk AI agents, Salesforce Agentforce, Decagon, Sierra | Hoeveel gesprekken werden geautomatiseerd of “contained”? | Meet meer volume dan juistheid |
| QA van gesprekken | Kaizo en andere QA-platformen | Was elk echt gesprek juist, toegestaan en goed afgehandeld? | Draait na het gesprek, niet voor een release |
Kaizo zit in de laatste rij. AutoPilot scoort elk afgehandeld gesprek tegen je eigen scorecard, en elke score linkt naar het bewijs in het gesprek. Je test de scoring tegen de historische beoordelingen van je team voordat ze live gaat, en beoordelaars houden de gesprekken die een oordeel vragen. Onze pagina over kwaliteitscontrole van AI-agents laat zien hoe het werkt in Zendesk en Salesforce.
Zie het op je eigen gesprekken. Kaizo scoort 100% van je supportgesprekken en zet de resultaten om in coaching. Demo boeken.
Wanneer dit niveau van evaluatie niet voor jou is
Handelt je AI-agent een paar dozijn gesprekken per week af, sla dan het raamwerk, de judge en de tool over: lees elk transcript zelf, een uur per week, met een korte checklist (juist, toegestaan, juiste overdracht, juiste toon). Begin het volledige programma wanneer het volume meer wordt dan één persoon kan lezen, of wanneer de agent acties gaat uitvoeren zoals terugbetalingen of accountwijzigingen.
Heb je een testsuite voor ontwikkelaars in je releasepipeline nodig, dan is dat een ander soort tool; het QA-platform van Kaizo scoort gesprekken nadat ze zijn afgelopen en kan ernaast draaien.
Hoe je deze week begint met het evalueren van AI-agents
Je kunt deze week beginnen met het evalueren van AI-agents zonder iets te kopen. In vijf dagen kan een supportteam drie intents kiezen, 30 echte fouten verzamelen, vijf criteria met ja of nee schrijven, 100 recente gesprekken scoren als baseline en eigenaren en drempels afspreken. De rest van het raamwerk groeit daaruit.
- Maandag: kies de intent met het hoogste volume, de riskantste (meestal terugbetalingen of accountwijzigingen) en de intent waarover klanten het meest klagen.
- Dinsdag: haal per intent 10 slechte gesprekken uit QA, klachten en escalaties; schrijf voor elk de juiste uitkomst in één zin.
- Woensdag: schrijf vijf criteria (juist antwoord, beleid, actie komt overeen met het systeem, escalatie, toon), elk als ja-of-neevraag met het bewijs dat het aantoont.
- Donderdag: twee beoordelaars scoren blind 100 recente gesprekken. Dat is je baseline en je eerste kalibratieset.
- Vrijdag: vul het raamwerk in met je namen, baselinecijfers en een datum voor de eerste maandelijkse review.
Geef de 30 fouten aan je AI-team als eerste regressieset: er gaat niets live tot die slaagt.
Veelgestelde vragen
Wat is een goede nauwkeurigheid voor een AI-agent in de klantenservice?
Er is geen universeel getal; het hangt af van wat één fout antwoord kost. Als voorbeelddrempel: mik op 98% of meer gesprekken zonder feitelijke fout en nul kritieke beleidsschendingen op je regressieset. Bepaal de live drempel op basis van je eigen baseline en onderzoek elke daling van 3 punten of meer.
Hoe vaak moet je de evals van een AI-agent opnieuw draaien?
Draai de regressieset opnieuw voor elke wijziging in prompt, model, tool of kennis, want elke wijziging kan iets breken dat werkte. Scoor gesprekken in productie doorlopend, bekijk de cijfers wekelijks, en kalibreer de judge maandelijks en na wijzigingen in de scorecard.
Moeten AI-agents op dezelfde scorecard worden beoordeeld als medewerkers?
Gebruik gedeelde criteria waar ze voor allebei gelden, zoals een juist antwoord en de juiste toon, zodat de resultaten vergelijkbaar blijven. Voeg daarna criteria toe die alleen een AI-agent nodig heeft: onderbouwing in je content, juistheid van acties, scope en escalatietriggers. Eén standaard met AI-specifieke controles werkt beter dan twee losse scorecards.
Wat is het verschil tussen pass@k en pass^k?
pass@k is de kans dat minstens één van k runs slaagt, wat past bij tools waar één goed antwoord genoeg is. pass^k is de kans dat alle k runs slagen. Klantenservice heeft pass^k nodig, want elke klant krijgt één run en verwacht elke keer het juiste antwoord.
Is het evalueren van AI-agents hetzelfde als AI-agent monitoring?
Nee. Monitoring houdt live volume, fouten en alerts in de gaten, zodat je een probleem snel opmerkt. Evaluatie beoordeelt of elk antwoord juist, toegestaan en goed afgehandeld was, voor de lancering op testcases en na de lancering op echte gesprekken. Evaluatie in productie voedt de monitoring, en elke fout die ze vindt, wordt een nieuwe testcase.
