Grüne Balken, trügerische Sicherheit: Was wir verlieren, wenn KI das Testen übernimmt

Eine Testsuite läuft durch, alle Checks sind grün, die Pipeline ist sauber. Kein Mensch hat einen einzigen Testfall formuliert, kein Mensch hat eine Erwartung in Prosa gefasst – ein KI-Agent hat das übernommen. Was auf den ersten Blick nach Effizienzgewinn aussieht, enthält auf den zweiten eine stille Gefahr: Das grüne Signal sagt immer weniger darüber aus, ob die Software tatsächlich das tut, was sie tun soll.

Agentenbasierte Testautomatisierung ist 2025 keine Zukunftsvision mehr. Tools wie GitHub Copilot Coding Agent (gestartet Mai 2025), Cognition Devin und eine wachsende Zahl spezialisierter Frameworks – von DeepEval bis LangSmith – generieren, strukturieren und bewerten Testfälle ohne direkten menschlichen Eingriff.¹ Die Versprechen sind real: weniger manueller Pflegeaufwand, schnellere Feedbackzyklen, bessere Abdeckung repetitiver Szenarien. Wer die Schattenseiten dieser Entwicklung ignoriert, wird von ihnen eingeholt.

Die zentrale These dieses Artikels lautet: Je mehr Testentscheidungen der KI überlassen werden, desto wichtiger – und desto seltener – werden fundierte menschliche Urteile. Und je seltener diese Urteile geübt werden, desto schlechter werden sie.

Technische und methodische Risiken

Das Oracle-Problem: Halluzinierte Korrektheit

Das sogenannte “Oracle-Problem” ist in der Softwaretestforschung seit Langem bekannt: Wer prüft, ob ein Testergebnis wirklich korrekt ist?² Bei KI-generierter Testautomatisierung verschärft sich dieses Problem erheblich. Large Language Models erzeugen Assertions, die syntaktisch plausibel wirken, aber semantisch falsch sind. Eine aktuelle Forschungsgruppe beschreibt das präzise: LLMs “halluzinieren Korrektheitskriterien (Oracle-Eigenschaften)” (sinngemäß übersetzt aus dem englischen Original) und verankern falsche Erwartungen direkt im generierten Testcode.³

Das ist kein akademisches Randproblem. Ein Messverfahren, das die Übereinstimmung zwischen LLM-Urteilen und tatsächlichen Testergebnissen untersucht, kam für GPT-4-turbo auf einen Cohen’s Kappa von ca. 0,21 (Java) und 0,10 (Python) – was in der statistischen Interpretation als schwache bis bestenfalls mäßige Übereinstimmung gilt.⁴ Anders formuliert: Ein nicht unerheblicher Teil der automatisch erzeugten Qualitätsaussagen ist methodisch fragwürdig.

Verlust von Nachvollziehbarkeit

Wer hat diesen Testfall mit welcher Begründung angelegt? Welche Anforderung deckt er ab? Warum wurde diese spezifische Eingabekombination gewählt? Auf diese Fragen können KI-generierte Testsuiten in der Regel keine befriedigende Antwort geben. Das ist nicht nur ein theoretisches Problem.

Regulatorische Rahmenbedingungen und Audit-Anforderungen verlangen eine lückenlose Rückverfolgung: von der Anforderung über den Testfall bis zum Ergebnis. Wenn KI-erzeugte Artefakte eingesetzt werden, müssen sie versioniert, mit Änderungshistorie versehen und menschlich freigegeben sein – und in Audit-Logs muss dokumentiert sein, wann und durch wen KI genutzt wurde.⁵ Die Übernahme von Verantwortung für maschinell erzeugte Testergebnisse setzt voraus, dass man diese Ergebnisse auch tatsächlich beurteilen kann.

Nicht-Determinismus und neue Flakiness

Flaky Tests – Tests, die ohne Codeänderung mal bestehen, mal scheitern – sind ein bekanntes Problem in der Testautomatisierung. KI-generierte Tests bringen eine neue Dimension dieser Unzuverlässigkeit mit. Eine aktuelle Studie zu LLM-generierten Tests für Datenbanksysteme fand, dass 63 % der produzierten flaky Tests auf Annahmen über Ergebnisreihenfolgen zurückzuführen waren, die schlicht nicht durch explizite ORDER-BY-Klauseln abgesichert wurden.⁶ Besonders aufschlussreich: Wenn dem Modell Beispielcode mit absichtlich eingebetteter Flakiness vorgelegt wurde, übernahmen die generierten Tests diesen Fehler in 42–78 % der Fälle – ein Beleg für “shortcut learning” (Lernen von oberflächlichen Mustern) ohne semantisches Verständnis.⁶

Hinzu kommt das strukturelle Problem des LLM-Nicht-Determinismus: Selbst bei identischen Eingaben und nominell deterministischen API-Einstellungen liefern gehostete Modelle in der Praxis unterschiedliche Ausgaben.⁷ Eine Testsuite, die gestern grün war, kann heute aus anderen Gründen scheitern oder bestehen – nicht wegen einer Codeänderung, sondern wegen der Stochastik des Sprachmodells.

Faktor Mensch – erodierende Kompetenzen

Test-Design-Kompetenz

Gute Testfälle entstehen nicht durch Ankreuzen von Zeilen. Sie entstehen durch die Entscheidung: Was muss ich prüfen, und warum genau? Diese Kompetenz – zu wissen, welche Äquivalenzklassen relevant sind, welche Grenzwerte kritisch, welche Zustandsübergänge riskant – entwickelt sich durch Übung. Wer stattdessen routinemäßig auf KI-generierte Testvorschläge setzt, ohne diese aktiv zu hinterfragen, verliert schrittweise die Urteilsfähigkeit, auf die es im Ernstfall ankommt.⁸

Folgerisiko: In Situationen, in denen die KI keine sinnvollen Vorschläge liefert – neuartige Architekturen, schlecht spezifizierte Anforderungen, komplexe Integrationsszenarios – fehlen die mentalen Werkzeuge für eigenständiges Vorgehen.

Domänen- und Anforderungsverständnis

Testen ist immer auch Anforderungsarbeit. Wer einen Test formuliert, fragt implizit: “Was soll die Software eigentlich tun?” Das erfordert Domänenwissen und die Bereitschaft, Anforderungen aktiv zu hinterfragen. KI-Tools umgehen diese Auseinandersetzung, indem sie aus vorhandenem Code oder vagen Beschreibungen direkt Testfälle ableiten. Was fehlt, ist die Fähigkeit der KI, in einem Requirements-Meeting zu sitzen und zu fragen: “Ist das wirklich gemeint?” oder “Historisch haben unsere Nutzer genau das abgelehnt.”⁹

Folgerisiko: Fehler in den Anforderungen werden durch automatisch generierte Tests nicht aufgedeckt – sie werden fortgeschrieben.

Exploratives Testen

Exploratives Testen ist keine improvisierte Aktivität; es ist eine kognitive Disziplin, die auf Neugier, Kontextwissen und die Fähigkeit zur situativen Hypothesenbildung angewiesen ist. KI kann keine Kreativität simulieren, die aus echtem Systemverständnis erwächst.¹⁰ Wer jahrelang primär KI-generierte Skripte abnickt, baut diese Disziplin nicht auf – oder verliert sie.

Folgerisiko: Unerwartete Systemverhalten, die keinem vordefinierten Muster folgen, werden nicht gefunden. Genau das sind oft die kritischsten Fehler.

Debugging und Root-Cause-Analyse

Wenn ein Test fehlschlägt, beginnt die eigentliche Arbeit: Was ist die Ursache? Ist es ein Bug im Produktionscode, ein Fehler im Testfall, ein Datenproblem, ein Umgebungsproblem? Diese Diagnose erfordert tiefes Verständnis des Systems unter Test. Wer die Architektur nicht mehr selbst durchdrungen hat, weil KI die Implementierungsdetails abstrahiert, verliert die Orientierungspunkte für die Fehleranalyse.

Folgerisiko: Lange Debugging-Zyklen, falsche Zuordnungen von Ursache und Wirkung, und im schlimmsten Fall: ein Bug wird als “Testproblem” eingestuft und geschlossen.

Werkzeug- und Framework-Verständnis

KI-Assistenten schreiben Testcode in Selenium, Playwright, pytest oder JUnit – ohne dass der Mensch dahinter noch versteht, wie diese Frameworks funktionieren, was ihre Grenzen sind, und warum bestimmte Patterns entstehen. Das ist kein Luxuswissen; es ist die Grundlage dafür, generierten Code beurteilen zu können.

Folgerisiko: Schlechte Architekturentscheidungen in der Testinfrastruktur werden nicht erkannt und skalieren zum technischen Schuldengebirge.

Der übergreifende Mechanismus: Ironien der Automation

Lisanne Bainbridge beschrieb 1983 in ihrem einflussreichen Aufsatz “Ironies of Automation” eine fundamentale Paradoxie industrieller Automatisierung:¹¹ Je mehr einem System überlassen wird, desto anspruchsvoller wird die Rolle des verbliebenen menschlichen Operators – und desto schlechter ist er darauf vorbereitet. Automatisierung eliminiert nicht die Notwendigkeit menschlichen Eingreifens; sie macht dieses Eingreifen seltener und damit schwieriger.

Bainbridge identifizierte unter anderem: Fähigkeiten degradieren, wenn sie nicht geübt werden. Wissen, das nicht regelmäßig abgerufen wird, verliert seine Verfügbarkeit. Und wer primär ein überwachender Beobachter eines korrekt laufenden Systems ist, verliert das Situationsbewusstsein (Situation Awareness), das er bräuchte, wenn das System aus dem Tritt gerät.¹²

Diese Ironien sind heute aktueller denn je. Eine 2020 erschienene Aktualisierung unter dem Titel “Ironies of Automation 4.0” zieht explizit die Linie von Bainbridges Originalthesen zur modernen Industrieautomation und KI-gestützten Entscheidungssystemen: Die Komplexität steigt, das Zeitfenster für Eingriffe schrumpft, und der menschliche Operator verliert genau dann an Kompetenz, wenn er sie am meisten bräuchte.¹³

Für KI-gestütztes Testen bedeutet das: Derjenige, der am Ende die Verantwortung für die Qualitätsaussage trägt, übt die Fähigkeiten nicht mehr, auf die diese Verantwortung eigentlich aufbaut. Das ist kein Managementproblem. Das ist ein strukturelles Problem jeder Automatisierungsstrategie, die Kompetenzerhalt nicht explizit adressiert.

Automation Bias – die Tendenz, Systemempfehlungen unkritisch zu übernehmen – verstärkt diesen Mechanismus. Parasuraman & Riley beschrieben 1997 in ihrer klassischen Taxonomie, wie Übervertrauen in automatisierte Systeme zu Überwachungsversagen und Entscheidungsverzerrungen führt.¹⁴ Neuere Forschung bestätigt den Effekt für KI-Assistenzsysteme in der Medizin: Eine im Lancet Gastroenterology & Hepatology veröffentlichte Studie fand, dass die unassistierte Adenom-Erkennungsrate von Endoskopikern nach regelmäßiger Nutzung KI-gestützter Koloskopie-Software von 28,4 % auf 22,4 % zurückging.¹⁵ Ein begleitendes Übersichtspapier ordnet diesen Deskilling-Effekt in einen breiteren Forschungsrahmen für das Gesundheitswesen ein.¹⁶ Der Mechanismus ist branchenunabhängig.

Rollenverschiebung: Vom Test-Ausführenden zum Test-Auditor

Die logische Antwort auf diese Entwicklung ist eine Rollenverschiebung: weg vom Testautor und Testausführenden, hin zum Test-Auditor. Der Mensch bewertet, was die KI produziert, statt es selbst zu schreiben. Das ist ein tragfähiges Modell – aber nur unter einer Bedingung: wenn die Auditing-Kompetenz aktiv aufgebaut und erhalten wird.

Das ist keine Selbstverständlichkeit. Ein Test-Auditor muss wissen, wie gute Testfälle aussehen, um schlechte zu erkennen. Er muss die Oracle-Qualität der Assertions beurteilen können. Er muss verstehen, welche Anforderungen ein Testfall abdeckt und welche nicht. Er muss feststellen können, ob ein generierter Test für die vorliegende Systemarchitektur überhaupt sinnvoll ist.

All diese Fähigkeiten setzen voraus, dass man sie zuvor durch aktive Testarbeit entwickelt hat – und dass man sie durch regelmäßige Praxis aufrechterhält. Ein Auditor, der nie selbst Testfälle entworfen hat oder diese Praxis jahrelang nicht mehr ausgeübt hat, ist kein Auditor. Er ist nur noch ein Stempel.

Organisationen, die KI-gestützte Testautomatisierung einführen, sollten daher zwei Fragen explizit beantworten: Wer in unserem Team hat die Kompetenz, KI-generierte Testfälle qualifiziert zu beurteilen? Und wie erhalten wir diese Kompetenz über die Zeit?

Fazit: Verantwortung lässt sich nicht automatisieren

KI-gestützte Testautomatisierung wird ein zentrales Werkzeug moderner QA-Arbeit bleiben – und das zu Recht. Die Effizienzgewinne bei repetitiven Regressionstests, bei der Testdatengenerierung und bei der initialen Testabdeckung sind real. Kein Praktiker, der die Realitäten von Testprojekten kennt, wird diese Vorteile ignorieren.

Die Gefahr liegt nicht in der KI selbst. Die Gefahr liegt in naiver Automatisierung: dem Vertrauen, dass grüne Balken Qualität bedeuten; dem Verzicht auf die Auseinandersetzung mit dem, was die KI tut; und dem schleichenden Abbau jener menschlichen Kompetenzen, die genau dann gebraucht werden, wenn das System versagt oder eine neue Frage auftaucht, für die kein Trainingsbeispiel existiert.

Bainbridges Ironie gilt auch hier: Die Automatisierung macht die menschliche Expertise nicht überflüssig – sie macht sie seltener und damit wertvoller. Die Frage ist, ob wir sie noch haben werden, wenn wir sie brauchen.

Wer KI verantwortungsvoll in QA-Projekte integriert, tut es mit einem Plan für Kompetenzerhalt, nicht nur mit einem Deployment-Skript.

QualiZeal, “The Rise of Agentic AI: Transforming Software Testing in 2025 and Beyond”, https://qualizeal.com/the-rise-of-agentic-ai-transforming-software-testing-in-2025-and-beyond/, 2025, abgerufen am 2026-06-09. — Autonoma AI, “AI E2E Testing and the LLM-Agent OSS Wave”, https://getautonoma.com/blog/ai-e2e-testing-in-2026, 2026, abgerufen am 2026-06-09. ↩
Weyuker, E.J., “On testing non-testable programs”, The Computer Journal, 25(4), 1982. — Barr, E.T. et al., “The Oracle Problem in Software Testing: A Survey”, IEEE Transactions on Software Engineering, 41(5), 2015. ↩
Zhang, R. et al., “Hallucination to Consensus: Multi-Agent LLMs for End-to-End JUnit Test Generation with Accurate Oracles”, arXiv:2506.02943, 2025, https://arxiv.org/abs/2506.02943, abgerufen am 2026-06-09. ↩
Xu, Q. et al., “On the Effectiveness of LLM-as-a-judge for Code Generation and Summarization”, arXiv:2507.16587, 2025, https://arxiv.org/abs/2507.16587, abgerufen am 2026-06-09. — Cohen’s Kappa ca. 0,21 (Java) / 0,10 (Python) für GPT-4-turbo bei LLM-basierter Testbewertung. ↩
TestRail, “Software Testing in Regulated Industries: From Traceability to AI Governance”, https://www.testrail.com/blog/testing-regulated-industries/, abgerufen am 2026-06-09. ↩
Berndt, A., Bach, T., Gemulla, R., Kessel, M. & Baltes, S. (SAP), “On the Flakiness of LLM-Generated Tests for Industrial and Open-Source Database Management Systems”, arXiv:2601.08998, ICSE-SEIP ‘26, https://arxiv.org/html/2601.08998v1, abgerufen am 2026-06-09. ↩ ↩²
Atil, B., Aykent, S., Passonneau, R. J. et al., “Non-Determinism of ‘Deterministic’ LLM System Settings”, arXiv:2408.04667, ACL Anthology (Eval4NLP 2025), https://aclanthology.org/2025.eval4nlp-1.12.pdf, abgerufen am 2026-06-09. ↩
Shukla, P., Bui, P., Levy, S. S., Kowalski, M., Baigelenov, A. & Parsons, P., “De-skilling, Cognitive Offloading, and Misplaced Responsibilities: Potential Ironies of AI-Assisted Design”, CHI 2025 Extended Abstracts, DOI 10.1145/3706599.3719931, arXiv:2503.03924, https://arxiv.org/pdf/2503.03924, abgerufen am 2026-06-09. ↩
Xray Blog, “AI and human intelligence in software testing”, https://www.getxray.app/blog/the-synergy-of-ai-and-human-intelligence-in-software-testing, abgerufen am 2026-06-09. — Scott Logic, “Is AI Taking Over Testing? Here’s Why Human Insight Still Matters”, https://blog.scottlogic.com/2025/08/21/is-ai-taking-over-testing-here-is-why-human-insight-still-matters.html, abgerufen am 2026-06-09. ↩
Bakshi, A., “Exploratory Testing 2.0: The Role of AI in Augmenting Human Expertise”, Medium, https://medium.com/@aseem.bakshi/exploratory-testing-2-0-the-role-of-ai-in-augmenting-human-expertise-99b7c9f8a67c, abgerufen am 2026-06-09. ↩
Bainbridge, L., “Ironies of Automation”, Automatica, 19(6), S. 775–779, Pergamon Press, 1983. DOI: 10.1016/0005-1098(83)90046-8. ↩
Friedrichsen, U., “AI and the Ironies of Automation – Part 1”, https://www.ufried.com/blog/ironies_of_ai_1/, abgerufen am 2026-06-09. ↩
Hancke, T., “Ironies of Automation 4.0”, IFAC-PapersOnLine 53(2), S. 17463–17468, 2020. https://www.sciencedirect.com/science/article/pii/S2405896320327737, abgerufen am 2026-06-09. — Gruber, H. & Sartori, J., “Ironies of Automation: Still Unresolved After All These Years”, ResearchGate, 2017, https://www.researchgate.net/publication/319196629. ↩
Parasuraman, R. & Riley, V., “Humans and Automation: Use, Misuse, Disuse, Abuse”, Human Factors, 39(2), S. 230–253, 1997. DOI: 10.1518/001872097778543886. ↩
Budzyń, K. et al., “Endoscopist deskilling risk after exposure to artificial intelligence in colonoscopy: a multicentre, observational study”, The Lancet Gastroenterology & Hepatology, 2025. DOI: 10.1016/S2468-1253(25)00133-5. — Unassistierte Adenom-Erkennungsrate (ADR) sank von 28,4 % auf 22,4 % (–6 Prozentpunkte absolut, ca. –20 % relativ). ↩
Natali, C., Marconi, L., Dias Duran, L., Miglioretti, M. & Cabitza, F., “AI-induced Deskilling in Medicine: A Mixed-Method Review and Research Agenda for Healthcare and Beyond”, Artificial Intelligence Review, Springer, 2025. DOI: 10.1007/s10462-025-11352-1. — Nguyen, M.H. et al., “Deskilling dilemma: brain over automation”, NCBI/PMC, 2025, https://www.ncbi.nlm.nih.gov/pmc/articles/PMC12909220/. ↩

Transparenzhinweis: Dieser Beitrag wurde KI-gestützt erstellt und vor Veröffentlichung redaktionell geprüft.