KI im Testing 2026: Werkzeug, Kollege, Prüfling
Eines vorweg: Ich sehe GenAI als Werkzeug. Und für Werkzeuge gilt: “A fool with a tool is still a fool.” Ich nutze die KI gern als Sparringspartner, gehe in den Dialog, arbeite mich durch die Ergebnisse. Aber ob Werkzeug oder Sparringspartner: Es ist wie im echten Leben. Wenn ich von der Materie keine Ahnung habe, kann mir mein Gegenüber erzählen, was es will. Ich kann es nicht bewerten. Daran hat sich nichts geändert. Geändert hat sich, wie gut die Werkzeuge geworden sind und wie viele Leute damit hantieren. Für die EuroSTAR 2026 gab es rund 550 Einreichungen, erzählte deren Program Chair kürzlich, etwa 300 davon drehten sich um KI im Testing. Der Anteil mit echten eigenen Erfahrungen: deutlich kleiner. Viel Meinung, wenig Praxis.
In meinen GenAI-Testing-Workshops halte ich es deshalb andersrum: Wir schauen nicht, was theoretisch möglich wäre, sondern was heute schon praktisch funktioniert. Und da hat sich einiges verschoben. Testfälle aus Anforderungen generieren? Macht inzwischen jeder. Copilot beim Skripten? Grundausstattung, keine Erwähnung mehr wert. Die Frage hat sich gedreht: von “Was kann die KI für dich tun?” zu “Was musst du prüfen, wenn sie mitarbeitet?” Fünf Felder, die ich gerade in Projekten und Trainings sehe.
Spezifikation statt Testfall-Prompt
Der Reflex ist verlockend: Code in den Prompt kippen, “schreib mir Tests dazu”, fertig. Dafür hat die Forschung inzwischen einen Namen: misguidance effect. Steckt ein Fehler im Code, schreibt das Modell brav Tests, die das Fehlverhalten als Sollverhalten festschreiben. Der Bug bekommt einen grünen Haken. Dazu passt eine Studie mit acht Modellen und über 22.000 Programmvarianten: Sobald sich der Code semantisch änderte, fiel die Pass-Rate der generierten Tests auf 66 Prozent, und über 99 Prozent der fehlschlagenden Tests waren auf der alten Version noch grün. Die Tests hatten das alte Verhalten auswendig gelernt, nicht die Anforderung verstanden.
Die Umkehrung funktioniert: spezifikationsbasiertes Prompting. Gib dem Modell die Anforderung, das erwartete Verhalten, die Randbedingungen, und lass es daraus die Tests ableiten. Das muss kein 80-Seiten-Lastenheft sein. Eine ordentliche User Story mit Akzeptanzkriterien reicht oft schon, ein API-Kontrakt, eine Zustandstabelle. Werkzeugseitig tut sich da gerade viel, GitHub hat sein Spec Kit im August in Version 1.0 veröffentlicht. Aber ehrlich: Das ist einfach eine saubere Testbasis. Das predigen wir im Testing seit Jahrzehnten.
Worauf du achten musst: Prompte aus der Spezifikation, nicht aus dem Code. Und wenn es keine Spezifikation gibt, ist genau das dein Befund.
Explorativ testen: der Agent klickt selbst
2025 hieß explorativ mit KI: Ich hole mir Testideen aus dem Chat. Das geht heute noch, aber es ist nicht mehr der interessante Teil. Playwright liefert inzwischen drei Agenten ab Werk: Der planner erkundet die Anwendung selbstständig und schreibt einen Testplan als Markdown, der generator baut daraus Tests, der healer repariert kaputte. Über MCP klickt sich der Agent wirklich durch die Anwendung, statt über sie zu fantasieren.
Das ist beeindruckend, wenn man es zum ersten Mal laufen sieht. Und trotzdem: Der Agent findet, was erreichbar ist. Nicht, was riskant ist. Er kennt eure Historie nicht, den Ärger mit der einen Schnittstelle, das Modul, das bei jedem Release bricht. Exploratives Testen lebt von Hypothesen, Erfahrung, Neugier. Der Loop liefert Breite. Die Fragen lieferst du.
Worauf du achten musst: Nimm die Agenten-Ergebnisse als Rohmaterial, nicht als Testkonzept. Die Priorisierung nach Risiko bleibt bei dir.
Testdaten: Fachlichkeit gelöst, Bereitstellung nicht
Für mich die stärkste Spannung im ganzen Thema. Fachliche Varianten kann das Modell hervorragend: Grenzfälle, kaputte Adressformate, exotische Vertragskonstellationen, alles in Sekunden. Nur nützt dir die schönste generierte Tabelle nichts, wenn sie nicht ins Testsystem kommt. Eine Umfrage des Werkzeugherstellers Perforce unter 518 Enterprise-Verantwortlichen zeigt das Ausmaß: 99 Prozent warten länger als einen Arbeitstag auf eine frische Produktionskopie, 42 Prozent Wochen oder Monate. Und das ist kein Ausreißer, auch der World Quality Report zählt sichere, skalierbare Testdaten weiter zu den häufigsten Stolpersteinen. Maskierung, referenzielle Integrität, Provisioning: alles so zäh wie eh und je. Das LLM löst die Fachlichkeit, nicht die Logistik.
Worauf du achten musst: Der Engpass sitzt in der Pipeline, nicht im Prompt. Bevor du Daten generierst, klär, wie sie ins System kommen.
Prüfen, was die KI baut
Code-Generierung ist Alltag geworden. Die Syntax stimmt fast immer. Die Sicherheit nicht: Veracode testet mit gleicher Methodik über 150 Modelle, und rund 45 Prozent der Generierungen enthalten eine bekannte Schwachstelle. Die Quote pendelt seit zwei Jahren zwischen 45 und 55 Prozent, und die Modellgröße ändert daran fast nichts. Die Modelle werden eloquenter, nicht sicherer.
Und die naheliegende Idee, die KI ihre eigene Arbeit prüfen zu lassen? Eine Studie auf der MSR ‘26 hat 3.109 Pull Requests untersucht: Wurden sie nur von Review-Agenten geprüft, lag die Merge-Rate bei 45 Prozent. Bei rein menschlichem Review bei 68. KI, die KI prüft, reicht offenbar nicht. Hier entsteht 2026 echte neue Testarbeit: Review-Gates für generierten Code, Security-Checks, und die unbequeme Frage, wer eigentlich noch versteht, was da gemerged wird.
Worauf du achten musst: Behandle generierten Code wie den Code eines neuen Kollegen. Schnell, fleißig, ohne Gespür für eure Altlasten. Das Review ist keine Formalie, es ist der Test.
KI-Features testen: Evals statt Assertions
Der fünfte Bereich dreht den Spieß um: nicht mehr KI im Testing, sondern Testing von KI. Wenn dein Produkt einen Chatbot, einen Assistenten oder eine RAG-Suche bekommt, testest du ein System, das auf dieselbe Eingabe verschieden antwortet. assertEquals läuft ins Leere. Stattdessen: Evals, Golden Datasets, LLM-as-Judge, Guardrails. Andere Werkzeuge, anderes Denken, aber im Kern die alte Frage: Was ist gut genug, und woran erkenne ich es?
Wie real das ist, zeigt eine Applause-Umfrage unter fast 1.100 Befragten: 44 Prozent haben live geschaltete KI-Features wieder abgeschaltet, weil die Betriebskosten den Nutzen überstiegen. Mehr als vier von zehn. Für mich ist das gerade die häufigste neue Testaufgabe überhaupt, und die wenigsten Teams sind darauf vorbereitet.
Worauf du achten musst: Definier vor dem Release, was “gut genug” heißt, und miss es laufend im Betrieb. Ein KI-Feature ohne Eval-Suite ist ein Blindflug mit Ansage.
Die Arbeit verschwindet nicht, sie wandert
Über alle fünf Felder zieht sich dasselbe Muster: Die Arbeit verschwindet nicht. Sie wandert. Vom Schreiben zum Prüfen, vom Ausführen zum Bewerten. Elmar Jürgens hat es auf den Software Quality Days schön gesagt: “Don’t stop doing as much quality assurance as you do now because it feels like we’re just moving faster …”
Und Prüfen braucht Urteilsvermögen. Das entsteht nicht beim Zuschauen, sondern beim Tun: beim Debuggen, beim Testdaten-Bauen, beim Streiten über Anforderungen. Wer das systematischer angehen will: Sogar das ISTQB führt inzwischen einen eigenen GenAI-Lehrplan. Wenn mir das Wissen fehlt, wird es gefährlich. Das galt schon immer. Aber 2026 gilt es mehr denn je, denn die Ergebnisse sehen inzwischen alle richtig aus. Ob sie es sind, merkt nur, wer es beurteilen kann.
