Testen, bevor jemand anruft

Eine Rechnungsprüfung lässt sich testen. Man gibt eine Rechnung hinein, vergleicht das Ergebnis mit dem erwarteten Wert, und der Test ist grün oder rot. Bei einem Sprachagenten funktioniert das nicht, und der Grund liegt an beiden Enden.

Am Eingang steht gesprochene Sprache. Dieselbe Frage klingt bei zwei Menschen verschieden, und dasselbe Anliegen wird in zehn Formulierungen vorgebracht. Am Ausgang steht ein Modell, das bei derselben Eingabe zweimal verschiedene Sätze bildet. Ein Vergleich auf Gleichheit misst dann die Formulierung.

Der Ausweg, den alle drei großen Werkzeugkästen gehen, ist derselbe: Man hält fest, was passieren sollte. Der Wortlaut bleibt dabei außen vor.

Der aufgezeichnete Testfall

Bei Dialogflow sieht das so aus. Man führt ein Gespräch im Simulator und speichert es. Gespeichert wird dabei, welche Absicht erkannt wurde, welcher Ablauf startete, welche Seite erreicht wurde.

When you save a test case, intent matches, playbook actions, activated flows, and activated pages that occurred during the conversation are saved as test case expectations.

Diese Erwartungen sind der Maßstab. Ändert man später etwas am Agenten, läuft der Testfall erneut, und geprüft wird gegen die Erwartungen.

When you run the test case later after making updates to your agent, these expectations are verified.

seitlich verschiebbar

eigene Darstellung nach der Dokumentation von Dialogflow CX, Stand 07.08.2026

Der Zweck steht im ersten Satz des Abschnitts: Fehler finden und Rückschritte verhindern.

You can use the built-in test feature to uncover bugs and prevent regressions.

Das zweite Wort ist das wichtigere. Ein Regressionstest hält fest, was gestern schon funktioniert hat. Über richtig sagt er nichts. Bei einem System, dessen Verhalten aus einem Modell und einer Handvoll Anweisungen entsteht, ist das der realistische Anspruch.

Was ein Testfall nicht sieht

Ein aufgezeichnetes Gespräch prüft den Weg, den es selbst genommen hat. Für alles andere ist es blind, und deshalb gehört zu jedem Testbestand die Frage, wie viel davon überhaupt berührt wird.

Beide Werkzeugkästen liefern dafür einen Bericht. Dialogflow zählt die Übergänge und die Absichten, Rasa sagt es deutlicher:

Coverage metrics help you see which flows and commands are not tested.

Das ist eine Aussage über den Testbestand. Über die Qualität sagt die Zahl nichts: Ein Sprachagent kann 90 Prozent Abdeckung haben und trotzdem an der ersten echten Frage scheitern, weil ein Anrufer sie anders stellt als der Testfall.

Ein Sprachagent besteht aus Stufen: Erkennung, Modell, Tool Call, Sprachausgabe. Jede davon lässt sich einzeln prüfen, und jede einzelne Prüfung ist billiger als die Prüfung des Ganzen.

Der Preis dafür steht in der Rasa-Dokumentation, und zwar in der Definition dessen, was ein End-to-End-Test ist:

End-to-End testing in Rasa checks your assistant as a whole system, from user message to final bot response or action.

Vom ersten bis zum letzten Glied. Das ist genau die Klasse von Fehlern, die eine Stufenprüfung strukturell nicht sieht: Die Erkennung liefert einen Text, das Modell versteht ihn, das Tool wird aufgerufen, und trotzdem hört der Anrufer etwas Falsches, weil zwei Stufen verschiedene Annahmen über dasselbe Feld haben.

Die Ausgabe ist ein Unterschied

Ein bestandener Test sagt wenig, ein gescheiterter soll sagen, was los ist. Rasa gibt deshalb eine Gegenüberstellung aus.

The CLI will print a summary of passing or failing test cases.

Any mismatches appear in a diff-like format, showing the expected versus actual events.

Erwartet gegen tatsächlich, Ereignis für Ereignis. Wer schon einmal einen Regressionstest gelesen hat, kennt die Form: Sie ist dieselbe wie beim Vergleich zweier Dateiversionen.

Das hat einen Nebeneffekt, der im Sprachkanal zählt. Ein Testlauf über zwanzig Gespräche erzeugt zwanzig Listen von Ereignissen. Anhören muss man davon nichts. Das ist lesbar, und es ist der Grund, warum überhaupt jemand einen solchen Bestand pflegt.

Wo der Testfall herkommt

Die Aufzeichnung im Simulator hat eine Eigenschaft, die man leicht übersieht: Sie macht den Testbestand zu einem Nebenprodukt der Arbeit. Wer ein Gespräch führt, um eine Änderung anzusehen, hat den Testfall schon in der Hand.

Dialogflow beschreibt genau diesen Weg:

To test your agent, you can use the simulator to interact with your agent and save the conversation as a test case.

Der zweite Weg führt über den Betrieb. Ein Gespräch, das schiefging, ist der beste Testfall, den es gibt: Er beschreibt einen Fehler, den jemand wirklich erlebt hat. Was dabei anfällt und wie man es auswertet, steht in Kapitel 12.

Bis hierher ist ein Testfall eine feste Erwartung: Diese Absicht, dieser Ablauf, diese Seite. Das genügt, solange das Verhalten an einer Absichtsliste hängt.

Sobald ein Modell die Entscheidung trifft, welches Tool aufgerufen und wann übergeben wird, gibt es Fragen, die sich so nicht mehr stellen lassen. Ob eine Antwort höflich war. Ob die Übergabe an einen Menschen zum richtigen Zeitpunkt kam. Ob der Agent bei seiner Aufgabe geblieben ist.

Der Weg dorthin führt über die Aufzeichnung eines ganzen Durchlaufs, und der Hersteller nennt das den schnellsten:

Trace grading is the fastest way to identify workflow-level issues.

Aufgezeichnet wird dabei die Kette selbst:

A trace captures the end-to-end record of model calls, tool calls, guardrails, and handoffs for one run.

Bewertet wird sie durch Kriterien statt durch einen Sollwert:

Graders let you score those traces with structured criteria so you can find regressions and failure modes at scale.

Damit ist die Prüfung selbst wieder ein Modell, mit allem, was das mit sich bringt. Ein Bewerter, der eine Antwort für höflich hält, ist eine Meinung mit Fehlerquote. Die Frage, wie man einer solchen Bewertung traut, stellt sich außerhalb des Sprachdialogs genauso, und Vibe-Coding / Agentic Engineering, Kapitel 07 nimmt sie sich vor.

Zwei Prüfungen, die man verwechseln kann

Eine Prüfung im Test und eine Prüfung im Betrieb sehen ähnlich aus und beantworten verschiedene Fragen.

Ein Guardrail läuft im Gespräch mit und entscheidet, ob eine Ausgabe hinausgeht. Er kostet Zeit, die der Anrufer hört, und er darf nichts durchlassen, was nicht durchgehen soll. Ein Testlauf hat kein Zeitbudget, keinen Anrufer und darf so gründlich sein, wie er will. Was Guardrails leisten und wo sie sitzen, steht in Kapitel 07.

Der Zusammenhang zwischen beiden ist der interessante Teil: Der Testlauf ist der Ort, an dem sich messen lässt, ob ein Guardrail seine Arbeit tut. Im Betrieb sieht man nur, dass er ausgelöst hat, nicht ob er richtig lag.

Was ein Testbestand über sich selbst sagt

Aus einem eigenen Projekt, einem Sprachagenten am Kiosk-Terminal: Über vier Monate Entwicklung stand der End-to-End-Test des Sprachwegs, also von Mikrofon über Verbindung und Sprachdienst bis zur Tonausgabe, als offener Punkt in der Aufgabenliste. Er wurde nie gebaut. Getestet wurde dabei durchaus, und zwar viel: Die Abdeckung im Vordergrund erreichte 68 Prozent über 774 Tests.

Die einzige Stelle mit einem Regressionsnetz war die Korrektur der Erkennung. Beobachtete Fehler wanderten dort in eine Testklasse und blieben geprüft. Die Wissenssuche, in der die meisten beobachteten Fehler auftraten, hatte kein einziges solches Netz.

Das Muster dahinter ist übertragbar: Ein Testbestand wächst dort, wo Tests leicht zu schreiben sind. Wo die Fehler sitzen, ist eine zweite Frage, und beides fällt selten zusammen. Die Abdeckungszahl sagt darüber nichts.

Was hier offen bleibt

Wie viele Testfälle genügen, dazu findet sich in den geprüften Quellen keine Zahl. Beide Werkzeugkästen liefern einen Abdeckungsbericht. Eine Schwelle, ab der ein Sprachagent als geprüft gilt, nennt keiner von beiden. Das ist ein Unterschied zur Softwareentwicklung, wo Abdeckungsziele üblich sind, und die Quellen sagen nicht, ob er Absicht ist.

Zur Wirksamkeit gibt es ebenfalls keine Messung. Keine der geprüften Quellen beziffert, wie viele echte Fehler ein Testbestand dieser Art vorher findet.