Warum beim Testen von KI dein Testkonzept plötzlich massiv anwächst…
Im vergangenen Artikel 1/5 Semantisches Testen nicht-deterministischer KI-Systeme haben wir uns die Grundlagen geschnappt: Nichtdeterminismus, Semantik und warum „Expected Result = <Single Value>“ bei KI-Assistenten ungefähr so sinnvoll ist wie ein Lineal, um Wind zu messen. Heute gehen wir einen Schritt weiter: Was bedeutet das für Qualitätssicherung als Disziplin? Also nicht nur für einzelne Tests, sondern für Strategie, Teststufen, Nachweisführung und Effizienz.
Wenn du einen KI-Assistenten testest, der Sprache versteht, Entscheidungen trifft und Umsysteme triggert, dann testest du nicht einfach eine Funktion. Du testest eine Kette von Fähigkeiten. Und du testest sie unter Bedingungen, die selten perfekt sind: Rauschen, Kontext, wechselnde Datenstände, variable Latenzen, Modellupdates, Multi-Intents, und international teils unterschiedliche Regeln und (Verhaltens-)Richtlinien. Der Effekt: Eine schier endlose Möglichkeit an funktionalen und nichtfunktionalen Rahmenbedingungen.
Deine QA muss dadurch sehr viel systematischer und pragmatischer vorgehen. Systematischer, weil du ohne Struktur im Möglichkeitsraum ertrinkst. Pragmatischer, weil du vor lauter explorativer Testvariationen nie fertig wirst.
Und genau an der Stelle wächst nicht nur dein Testfallkatalog. Dein Testkonzept selbst bläht sich auf: Du brauchst plötzlich zusätzliche Testvorgehen mit individuellen Definitionen für Akzeptanzkorridore, neue Bewertungslogiken und erweiterte Stabilitätskriterien plus neue Regeln, wie du Ergebnisse überhaupt als „nachgewiesen“ deklarierst.
Die Herausforderung des Unbekannten
Jetzt kommt erschwerend hinzu, dass das Herzstück dieses Verbunds – ein integriertes Sprachmodell, egal von welchem Anbieter – zwangsläufig als Fremdeinheit betrachtet werden muss, weil sein Verhalten nicht über klassische Spezifikationen vollständig festgelegt und reproduzierbar vorhergesagt werden kann. Für uns im Test ist das besonders relevant, weil damit zu der ohnehin explodierenden Kombinatorik noch eine zweite Dimension hinzukommt: unbekanntes Verhalten innerhalb eines Systems, das trotzdem verlässlich funktionieren muss.
Viele integrierte Sprachmodelle werden als fertige Basislösung übernommen oder lediglich punktuell weiterentwickelt (Updates, Fine-Tuning, Safety-Layer), ohne dass das Projektteam jede interne Entscheidungslogik kontrollieren oder beeinflussen kann. Damit bleibt im Kern nur eine saubere Konsequenz: Du behandelst das Modell wie eine Blackbox und weist Qualität über beobachtbares Verhalten und Wirkung im Systemverbund nach.
Und als wäre das nicht schon sportlich genug, bringt diese Komponente noch ein paar sehr konkrete Nebenwirkungen für die Qualitätssicherung mit.
Erstens werden Fehlerbilder schwerer greifbar: Wenn eine KI-getroffene Reaktion „danebenliegt“, ist oft nicht sofort klar, ob die Ursache in der Intent-Erkennung, im Kontextmanagement, in der Tool-Auswahl oder in der sprachlichen Ausgabe liegt – und selbst bei identischem Testaufbau kann der nächste Lauf plötzlich wieder gut aussehen.
Zweitens verschiebt sich der Charakter der Anforderungen. Bei deterministischen Komponenten kannst du sehr präzise spezifizieren, was passieren muss.
Bei einem LLM-involvierten Test musst du hingegen akzeptieren, dass sich Teile der Spezifikation nur als Leitplanken formulieren lassen: Welche Informationen sind zwingend, welche Formulierungen sind zulässig, wie muss Unsicherheit kommuniziert werden, wann ist nachzufragen, wann ist abzulehnen?
Diese aufgeweichten Anforderungen sind schwerer abzustimmen, zu operationalisieren und konsistent zu bewerten, besonders wenn unterschiedliche Stakeholder unterschiedliche Erwartungen an „gute“ Antworten haben.
Drittens entsteht eine zusätzliche Dynamik durch Kontext und Datenabhängigkeit. Ein Assistent reagiert nicht nur auf den aktuellen Satz, sondern auf Gesprächshistorie, Nutzerzustand, verfügbare Daten und Systemantworten anderer Komponenten.
Qualität im Verbund: Warum End-to-End-Tests entscheidend sind
Im klassischen Testvorgehen kannst du viele Qualitätsmängel „unten“ im V abfangen: Unit-Tests, Integrationstests, dann Systemtests. Eindeutiger Meldungsverkehr an den Schnittstellen gibt dir früh ein gutes Gefühl, welchen Reifegrad dein System haben müsste. Für alle involvierten Umsysteme mit klassischer Entwicklungsbasis gilt das auch weiterhin in diesem Verbund
Sobald aber eine KI die Steuerung deines Verbunds übernimmt, zeigen sich die entscheidenden Probleme oft erst, in der End-to-End-Sicht. Warum? Weil die Fehler nicht nur in einer Komponente stecken, sondern in der Variabilität, in der ein Orchestrator das Gesamtsystem „moderiert“, weil es keine absolut eindeutigen Inputs und Reaktionen darauf gibt.
Stell dir einen KI-Assistenten im Fahrzeug vor: Der Fahrer sagt: „Mir ist kalt“. Wie interpretiert das Sprachmodell die Ansage? Vielleicht mit 2 Grad wärmer? Oder es macht das Fenster zu und aktiviert die Sitzheizung. Oder doch alles zusammen?
Jede Reaktion ist für sich genommen vielleicht plausibel, aber das Gesamtergebnis ist für den Nutzer möglicherweise trotzdem falsch. Und die Verantwortung für den gewünschten Effekt liegt nicht mehr beim Anwender, den Befehl richtig aufzusagen, sondern bei der KI, ihn richtig zu interpretieren und bei Unklarheiten sinnvoll zu reagieren. Also erwarten wir eigentlich statt einer Zufallsreaktion als “richtige” Verhaltensoption, dass unser Assistent bei Unklarheiten im Dialog mit dem Fahrer die wirkliche Intention ermittelt.
End-to-End-Teststrategie für KI-Assistenten
Ein sauberer E2E-Ansatz für Assistenten denkt deshalb in Nutzerzielen und Systemreaktionen. Du definierst für einen Use Case nicht nur „Was soll passieren“, sondern auch „Woran erkenne ich, dass es wirklich passiert ist?“.
Methodisch bedeutet das: Du baust Szenarien entlang einer Kette auf. Input (Sprache/Text), Interpretation (Intent/Parameter), Entscheidung (darf ich das?), Ausführung (Umsystem-Trigger), Rückmeldung (Antwort an Nutzer).
In dieser Reihenfolge liegt auch die Debug-Logik: Wenn etwas schiefgeht, willst du wissen, ob die Absicht falsch verstanden wurde, ob Parameter falsch abgeleitet wurden, ob das Umsystem anders reagiert hat als erwartet, oder ob „nur“ die Rückmeldung danebenliegt.
Dafür müssen klare Verantwortungsgrenzen definiert sein: Welche Entscheidungen darf die LLM treffen, welche nur vorbereiten, und welche müssen deterministisch außerhalb entschieden werden?
Genauso entscheidend ist aber hier auch die Frage: Was darf die Komponente nicht tun? Das sind deine Guardrails, die wir kommende Woche inhaltlich tiefer legen werden. Du brauchst klare No-Go-Regeln.
Die Folge des Ganzen? Unendliche Kombinationsmöglichkeiten
Strukturierte und wiederholbare Tests trotz unendlicher Kombinationsmöglichkeiten
Das Wichtigste: E2E-Tests bei KI-Assistenten sind nicht mehr nur standardisierte „Systemtests wie früher“. Sie sind die Stelle, an der du Nichtdeterminismus nur beherrschbar machen kannst, wenn du hier die, eingangs erwähnten verbindlichen Leitplanken, also Akzeptanzkorridore und Messpunkte festlegst, die für dich relevant sind. Du solltest dabei weniger auf Masse aller denkbaren Use Cases gehen, sondern die wirklich wichtigen und relevanten Szenarien mit einem Möglichkeitsspektrum identifizieren.
Dann definierst du die erwartete „statistische“ Stabilität: Wie oft muss mein System “richtig” liegen? Hier kommen nun die im letzten Artikel erwähnten Erfolgsraten ins Spiel. Denn um Vertrauen in das Verhalten zu erlangen, ist es sinnvoll, besonders relevante Szenarien wiederholt zu testen und eine Mindesterfolgsquote festzulegen, um nachzuweisen, ob du gerade ein robustes Verhalten oder nur Glück beobachtet hast.
Du testest dabei nicht alle Möglichkeiten ab, sondern coverst in diesem definierten Aktionsradius einen Möglichkeitsraum.
Zu guter Letzt stellst du die erwartete Transparenz nach außen sicher: Auch wenn du deine Blackbox nicht aufschrauben kannst, willst du Diagnosefähigkeit. Du brauchst Logs, Traces, Request/Response-Korrelationen, Kontext. Im Test kann dir ein z.B. ein protokolliertes Reasoning aufzeigen, wie es zu dem Verhalten kam. Ganz wichtige Voraussetzung daher: Im Test muss der Zugriff auf Informationen zum gesamten Ablauf von der Eingabe bis zum Ergebnis vollständig gewährleistet sein und bei jedem Testlauf stets mit aufgezeichnet werden.
Du testest repräsentativ, risikobasiert und systematisch.
Der erste Hebel ist Clustering: Du bündelst Eingaben in Klassen. Viele Formulierungen gehören zur gleichen Absicht. Viele Absichten gehören zur gleichen Domäne. Viele Domänen gehören zur gleichen Risikokategorie. Eingangskriterium hierfür ist eine seriöse Risikoanalyse. Fehlt diese, starte damit, sobald du deine Clusterkategorien erkannt hast. Dadurch entsteht eine Hierarchie, mit der du eine verlässliche Coverage erreichen kannst. Du testest nicht „jeden Satz“, du testest „jede wichtige Klasse“. Getreu dem Motto: „Ich muss nicht jedes Blatt anschauen, um zu wissen, ob der Baum gesund ist.“
Der zweite Hebel ist kontrollierte Variation: Du testest nicht unter möglichst „stabilen“ Bedingungen, sondern variierst gezielt entlang zentraler Einflussfaktoren (Sprache, Kontext, Tool-Resultate) und prüfst Akzeptanzkorridore. Ein Akzeptanzkorridor beschreibt dabei nicht den exakten Wortlaut, sondern den Rahmen, in dem Bedeutung, Handlung und Tonalität unter Wahrung von definierten No-Go-Grenzen als „korrekt genug“ gelten. Über Variationen beweist du die Robustheit des Systems.
Der dritte Hebel ist das richtige Design von Messpunkten in deinem Expected Result: Wenn du das Umsystem als Wahrheitspunkt nutzt, kannst du Ergebnisse reproduzierbar prüfen, selbst wenn die Antwortformulierung variiert. Die ausgelöste Reaktion deiner Zielfunktion ist entscheidend. Und dadurch gelingt es dir auch wieder, den Anteil „semantischer Bewertung“ zu reduzieren und den Anteil objektiver Prüfungen über den Systemzustand zu erhöhen.
Der vierte Hebel ist Regression als Einstiegsritual in den Testcycle: Nichtdeterministische Systeme brauchen eine andere Regressions-Philosophie. Du willst nicht nur gelegentlich wissen „ist es heute immer noch grün“, sondern ständig „wo bleibt es im Trend stabil“. Deshalb sind wiederholbare, regelmäßig laufende Kernsets wichtig – und zwar so, dass du Veränderungen im Verhalten schnell erkennen kannst, um dann für die umfangreichen Testsets potenzielle Schwerpunktfelder zu identifizieren.
Wenn du das alles kombinierst, entsteht etwas, das für Testing von KI existenziell ist: Beherrschbarkeit durch Struktur. Du akzeptierst die Unendlichkeit theoretisch, aber du baust dir eine praktische Landkarte, auf der du navigieren kannst.
Abschluss und Ausblick
Heute hast du gesehen, warum KI die QA-Experten nicht „abschafft“, sondern ihre Aufgabe anspruchsvoller macht. Und der E2E-Test gewinnt noch viel mehr an Bedeutung. KI-Systeme testest du nur durch klar definierte Erwartungen, Stabilitätskriterien und eine echte Teststrategie. Und die unendliche Kombinatorik besiegst du nicht mit Masse, sondern mit Struktur
Klasse, dass du bis hierhin durchgehalten hast. Welche Erfahrungen hast du im Test von KI-Systemen gemacht? Und wenn du beim Lesen gemerkt hast: „Okay, das ist genau unser Problem – wir haben KI drin, aber unser Testvorgehen ist wohl Schnee von gestern“, dann ist das ein ziemlich verbreiteter Zustand im Jahr 2026. Genau da setzt meine Beratung an: QCT unterstützt Teams dabei, aus einem KI-Prototypen ein beherrschbares Produkt zu machen. Meld dich und wir schauen uns dein Szenario genauer an
Nächste Woche wird’s ernst und “erzieherisch”. Guardrails, Ethik, Bias, Missbrauch und toxisches Verhalten. Wir schauen uns an, wie du solche Themen angehst – inklusive Provokations- und adversarialer Szenarien, die dein System aus der Reserve locken sollen oder so richtig aufs Kreuz legen sollen.
Artikel verpasst?
In der CT View findest du alle zum nochmal genießen.
