Workflow
Agentic QA: Testen mit und gegen KI-Agenten
KI-Agenten schreiben Tests und müssen selbst getestet werden. Was agentische QS heute leistet, wo sie scheitert, und wie sich die QA-Rolle verändert.
"Agentic QA" ist gerade das Schlagwort der Testbranche, und es meint zwei sehr verschiedene Dinge, die oft in einen Topf geworfen werden. Erstens: KI-Agenten übernehmen Aufgaben der Qualitätssicherung, schreiben und pflegen Tests selbst. Zweitens: Die KI-Agenten, die ihr ins Produkt baut, müssen selbst getestet werden, und dafür reicht klassische QS nicht mehr. Beide Seiten verändern die Arbeit von QA-Profis spürbar. Sehen wir sie uns einzeln an.
Seite 1: Agenten übernehmen die Testarbeit
Der erste und naheliegende Teil: Agenten erledigen QS-Routine, die bisher viel Zeit gefressen hat. Konkret laufen heute vor allem diese Aufgaben:
- Testfälle aus Anforderungen erzeugen. Aus User Stories, Requirements oder einer Beschreibung in natürlicher Sprache generiert ein Agent vollständige Testfälle. Tricentis beschreibt das als Testgenerierung, die "complete test cases from natural language prompts, user stories, or requirements" erstellt.
- Testlücken finden. Agenten analysieren laufend Code-Änderungen und zeigen, wo Abdeckung fehlt.
- Lasttest-Szenarien bauen. Realistische Nutzerlast-Muster lassen sich beschreiben statt von Hand modellieren.
- Explorative Tests unterstützen. Der Agent probiert Pfade durch, an die im Skript niemand gedacht hat.
Das ist echte Entlastung, vor allem bei der Fleißarbeit. Wer schon mit KI im Testing arbeitet, kennt den Einstieg dazu aus KI im Testing: bessere Tests, weniger Routine.
Die nüchterne Seite davon
Jetzt der Teil, den die Tool-Anbieter leiser sagen. Mehr generierte Tests heißt nicht automatisch bessere Qualität. Ein Agent, der hundert Testfälle ausspuckt, erzeugt vor allem hundert Dinge, die jemand verstehen, prüfen und pflegen muss. Drei Zahlen, die Tricentis selbst nennt und die zur Vorsicht mahnen:
- Mindestens 60 Prozent des KI-generierten Codes enthält Probleme, die einen Eingriff brauchen.
- 95 Prozent der KI-Pilotprojekte scheitern, weil passende Leitplanken fehlen.
- 88 Prozent der bei Stack Overflow Befragten sind unsicher, KI-Code zu deployen.
Die Lehre ist nicht "lass es bleiben", sondern: Der Output eines QS-Agenten ist ein Entwurf, kein Ergebnis. Er braucht ein menschliches Urteil darüber, ob die Tests das Richtige prüfen. Das deckt sich mit dem, was wir zur Code-Qualität mit KI geschrieben haben: Das "fast richtig" ist die eigentliche Gefahr.
Seite 2: Wie testet man einen Agenten?
Die zweite Bedeutung ist die kniffligere. Sobald ihr selbst einen KI-Agenten ins Produkt baut, einen Support-Bot, einen Recherche-Assistenten, ein Feature mit LLM darunter, bricht die Grundannahme klassischer QS weg. Klassische Testautomatisierung wurde gebaut, um Vorhersagbarkeit zu prüfen. Bei einem Sprachmodell kann dieselbe Eingabe zweimal zwei deutlich verschiedene Antworten liefern, die beide korrekt sind.
Damit funktioniert die alte Frage "Ist die Ausgabe exakt gleich der erwarteten?" nicht mehr. Sie wird ersetzt durch "Ist die Ausgabe gut genug?". Das klingt weicher, ist aber testbar, nur eben anders:
| Klassische QS | QS für KI-Agenten |
|---|---|
| Erwartet exakt gleiche Ausgabe | Akzeptiert mehrere gültige Ausgaben |
| Ein Lauf reicht | Mehrere Läufe, statistische Aussage |
| Binär: bestanden oder nicht | Bewertung mit Toleranz und Konfidenz |
| Vergleich Zeichen für Zeichen | Vergleich nach Bedeutung (semantisch) |
Praktisch heißt das, ihr braucht zusätzliche Prüf-Schichten. CloudQA beschreibt dafür mehrere, die sich bewährt haben:
- Semantische Validierung statt Textvergleich. Statt auf identische Wörter zu prüfen, wird die Bedeutung verglichen, etwa über Embedding-Ähnlichkeit. Liegt die Antwort inhaltlich nah genug an der Referenz, gilt sie als richtig.
- Adversariales Testen. Gezielte Angriffe wie Prompt Injection gehören in die Testsuite, nicht erst ins Security-Audit nach dem Launch.
- Drift-Überwachung. Modelle ändern sich, auch ohne dass ihr etwas anfasst. Was gestern bestand, kann nach einem Modell-Update kippen, also gehört kontinuierliche Beobachtung dazu.
Dazu kommt eine Methode, die direkt aus der probabilistischen Natur folgt: mehrfache Läufe. Weil eine einzelne Antwort wenig aussagt, testet ihr dieselbe Eingabe mehrmals und beurteilt das Verhalten über die Verteilung, nicht über den Einzelfall.
Ein nicht-deterministischer Test ist hier kein Bug, der wegmuss, sondern eine Eigenschaft des Systems, mit der die Testsuite umgehen können muss.
Die QA-Rolle verschiebt sich
Beide Seiten laufen auf dasselbe hinaus. Wer QA macht, pflegt künftig weniger Skripte und trifft mehr Entscheidungen. Tricentis bringt es so auf den Punkt: QA-Verantwortliche werden zu "orchestrators, defining quality objectives and overseeing AI-driven outcomes rather than executing every test themselves". Vom Test-Ausführer zum Qualitäts-Koordinator.
Das ist keine Abwertung, im Gegenteil. Die Aufgaben, die bleiben, sind die anspruchsvollen: definieren, was "gut genug" überhaupt heißt, die Leitplanken für die Agenten setzen, beurteilen, ob ein generierter Test das Richtige prüft, und entscheiden, wann man dem System traut und wann nicht. Das ist Handwerk, das ein Agent nicht ersetzt.
Was das für euch heißt
Drei Dinge zum Mitnehmen:
- Nutzt Agenten für die Testarbeit, aber behandelt ihren Output als Entwurf. Generierte Tests sind ein Vorschlag, den ihr prüft, nicht ein fertiges Sicherheitsnetz.
- Wenn ihr KI ins Produkt baut, plant die QS dafür von Anfang an anders. Semantische Bewertung, mehrere Läufe und Drift-Überwachung gehören eingeplant, bevor das Feature live geht.
- Investiert in das Urteil, nicht nur in die Tools. Der Wert der QA-Rolle liegt zunehmend darin, Qualität zu definieren und zu beurteilen, nicht darin, Tests von Hand zu tippen.
Welche konkreten Werkzeuge und Skills den Einstieg erleichtern, steht in Bewährte Skills für QA. Wer die KI-Seite im Testing erst kennenlernt, fängt am besten bei KI im Testing an.