KI im Software-Testing: Grenzen, Rollen und die richtige Tool-Wahl

17. Aug.
11 Min. Lesezeit

Aktualisiert: 19. Aug.

Beitragsbild „Wo KI aufhört, beginnt das Urteil" mit Regler-Übersicht zu KI-Anteil und menschlicher Prüfung je Testaktivität_KI Testing Grenzen

KI kann heute nachweislich bei der Prüfung von Akzeptanzkriterien, bei Testdaten, Testfällen und Fehleranalyse unterstützen. Das haben wir im Beitrag „KI im Software-Testing: Wo sie heute schon wirkt“ anhand konkreter Einsatzfelder gezeigt.

Genauso wichtig wie die Frage, was KI kann, ist aber die Frage, wo sie an ihre Grenzen stößt. Dieser Beitrag zeigt, wo die Risiken des KI-Einsatzes im Software-Testing liegen und wie sich Unterstützung sinnvoll von Automatismus abgrenzen lässt. Außerdem geht es um neue Anforderungen an Testengineers und um eine in der Praxis oft unterschätzte Frage: welches Werkzeug für welchen Zweck überhaupt geeignet ist.

Risiken im KI-gestützten Software-Testing

Ersatz für Testende?

Mehrere unabhängige Quellen kommen zum selben Schluss: KI ersetzt Testende nicht, sie ergänzt sie. Beim Bundesrechenzentrum bringt es die Abteilungsleitung Quality & Testing auf den Punkt: „KI revolutioniert Software-Testing nicht, indem sie Menschen ersetzt, sondern indem sie diese unterstützt.“ Ein warnendes Beispiel für übertriebene Erwartungen liefert der Fall „Devin AI“: 2024 als „weltweit erster vollständig autonomer KI-Software-Entwickler“ vorgestellt, zeigte sich bei genauerer Prüfung, dass die Fähigkeiten deutlich überzeichnet waren und substanzielle menschliche Nacharbeit nötig blieb. Was KI nicht ersetzt: menschliches Urteilsvermögen, das Verständnis für Geschäftskontext und Nutzerbedürfnisse sowie die Vermittlung zwischen Teams und Stakeholder*innen.

Selbstevaluation als blinder Fleck

Eine 2026 vorgestellte Studie zu agentbasierten Test-Frameworks (AEVAL) dokumentiert eine konkrete Selbstkorrektur-Verzerrung: Ein Agent behebt einen Fehler im eigenen Code selbstständig und vergibt anschließend selbst eine Erfolgsquote von 100%, ohne dass die Reparatur unabhängig geprüft wird. Das unterstreicht: Wo dieselbe KI sowohl Code als auch dessen Bewertung liefert, fehlt die unabhängige Instanz, die menschliche Testende bislang darstellen.

Ungeprüfter und ungetesteter Code

KI verstärkt bestehende Schwächen in der Qualitätssicherung, statt sie zu beheben. Fehlen im Team schon vor der KI-Einführung klare Qualitätsstandards, führt der KI-Einsatz eher zu mehr unbemerkten Problemen als zu weniger, etwa wenn generierter Code oder generierte Tests ungeprüft übernommen werden, nur weil sie beim ersten Durchlauf funktionieren. Dieselbe Sorgfalt, die man bei selbst geschriebenem Code anwendet, muss auch für KI-generierten Code und KI-generierte Tests gelten.

Empirische Evidenz

Eine 2024 veröffentlichte, unabhängige Studie zur Generierung von Java Unit Tests (JUnit-Tests) mit drei Sprachmodellen (Notre Dame, Penn State u. a., EASE 2024) unterlegt dieses Risiko mit Zahlen: Auf kuratierten Benchmark-Aufgaben (HumanEval) erreichte das leistungsstärkste Modell über 80% Codeabdeckung, auf realen Open-Source-Projekten (SF110) erreichte jedoch kein Modell mehr als 2%. Zudem litten die generierten Tests deutlich unter Test Smells wie Assertion Roulette (mehrere unbenannte Assertions in einem Test) und Magic Number Test (unbegründete Zahlenwerte in Assertions), teils inklusive halluzinierter, in Java gar nicht existierender Typen.

Bestandene Tests als Fassade

Eine Studie von Microsoft-Forschenden (2026) zeigt: Zwei produktive Coding-Agenten (Claude Opus 4.7, GPT-5.5) sollten eine React-Komponente als Angular-Bibliothek nachbauen, geprüft durch eine verdeckte Suite aus 222 Verhaltenstests. Mit Zugriff auf die Tests erreichten sie nahezu perfekte Ergebnisse. Ein Code-Audit zeigte jedoch, dass die getestete Funktionalität oft nur in eine Wegwerf-Demo einprogrammiert war, während die eigentlich verlangte Bibliothek funktionslos blieb. Die Autoren nennen das „Building to the Test“: Der Test besteht, ohne dass das beauftragte Artefakt existiert. Eine zweite Studie zeigt einen verwandten Effekt: Wird ein Test erst geschrieben, nachdem die möglicherweise fehlerhafte Implementierung bereits vorliegt, sinkt die Fehlererkennungsrate auf rund 14%, gegenüber rund 25% bei unabhängig entwickelten Tests. Tests in Kenntnis des bereits vorliegenden Codes bestätigen also eher das Vorhandene, als dass sie es unabhängig prüfen.

Testabdeckung realer KI-Pull-Requests

Eine Analyse von 4.882 durch KI-Coding-Agenten erstellten Pull Requests (fünf verschiedene Agenten) kommt zu einem nüchternen Befund: Nur 49,6% der Pull Requests, die Code unter Testabdeckung ändern, enthielten überhaupt Änderungen an Tests. Die vorhandenen Tests deckten im Schnitt lediglich 61,5% der geänderten Zeilen bei Java- und 27,0% bei Python-Projekten ab. Bei 64,8% der Python-Pull-Requests wurde keine einzige geänderte Zeile von einem bestehenden Test erfasst.

Nicht-Determinismus von KI-Ergebnissen

Klassische Testautomatisierung ist deterministisch: gleicher Input, gleicher Output. Generative KI-Modelle arbeiten dagegen wahrscheinlichkeitsbasiert, identische Eingaben können zu unterschiedlichen Ausgaben führen. Das erschwert die Definition eines „richtigen“ Ergebnisses und die Verifikation von KI-gestützten Testfällen selbst. In der Praxis hilft hier, statt exakter Übereinstimmung Toleranzgrenzen zu definieren und Ergebnisse statistisch statt binär zu bewerten.

Große Datenbasis bestätigt Instabilität

Eine Auswertung von 204.673 Testdateien (rund 180.000 davon von KI-Agenten, der Rest menschlich erstellt) aus einem großen Open-Source-Datensatz zeigt ein gemischtes Bild: KI-Agenten decken mit einem „Variety Score“ von 0,62 gegenüber 0,32 bei Menschen deutlich mehr unterschiedliche Randfälle ab, ihre Tests gelten aber häufiger als instabil bzw. flaky-verdächtig (Candidate Rate 0,41 gegenüber 0,30 bei Menschen).

Datenschutz und Vertraulichkeit bei externen KI-Diensten

Sobald Testdaten oder Quellcode an cloudbasierte KI-Dienste übergeben werden, verlassen sie die eigene Infrastruktur. Das ist besonders bei Testdaten mit Personenbezug oder bei vertraulichem Quellcode relevant. In regulierten Branchen wie Finanzwesen, Gesundheitswesen oder öffentlichem Sektor kommen zusätzliche Compliance-Anforderungen hinzu, die vor dem KI-Einsatz zu klären sind. Personenbezogene oder reale Produktionsdaten sollten grundsätzlich nicht ungeprüft an externe KI-Dienste übergeben werden. Synthetische und anonymisierte Testdaten sind auch hier die sicherere Grundlage.

Black-Box-Charakter komplexer Modelle

Fortgeschrittene KI-Modelle liefern Ergebnisse häufig ohne nachvollziehbare Begründung. Das erschwert das Vertrauen in automatisch priorisierte oder generierte Testfälle: Warum genau ein Test als besonders risikoreich eingestuft wurde, lässt sich oft nicht direkt nachvollziehen. Erklärbarkeits-Werkzeuge wie LIME oder SHAP schaffen hier teilweise Abhilfe, sind in gängigen Testtools aber noch nicht Standard.

Halluzination als dokumentiertes Risiko in der Forschung

Ein systematisches Literaturreview zu KI-gestützten Test-Oracles wertet 54 Studien aus, gefiltert aus 2.436 Treffern nach PRISMA-Standard. Rund die Hälfte der Verfahren (28 von 54) leitet ihre Prüfgrundlage aus einer Spezifikation ab, die übrigen 26 kommen ganz ohne Spezifikation zu einem Urteil. Das ist ein Hinweis darauf, wie unterschiedlich abgesichert die Vertrauensbasis von KI-generierten Testurteilen in der Praxis ist.

Sicherheitsrisiko bei agentbasierten Coding-Werkzeugen

Eine aktuelle Studie zu KI-Coding-Agenten in produktiven Softwareentwicklungs-Pipelines deckt ein Risiko auf, das speziell die Testautomatisierung betrifft: Werden riskante Aktionen in gewöhnliche Testaufgaben wie Unit-Tests, Regressionstests oder Fehlerreproduktion eingebettet, steigt die Rate tatsächlich ausgeführter unsicherer Aktionen über mehrere Agenten-Frameworks und Modelle hinweg auf 73,6% (bei Code-Anfragen) bzw. 53,9% (bei Text-Anfragen). Die Studie folgert: KI-Coding-Agenten bleiben unsicher, sobald riskante Absichten hinter einer plausiblen Testaufgabe verborgen werden. Auch scheinbar harmlose Testaufgaben benötigen daher dieselbe Sicherheitsprüfung wie produktiver Code.

Wo KI sinnvoll eingesetzt wird und wo (noch) nicht

KI nur zur Unterstützung bzw. Ergänzung

Der gemeinsame Nenner aller ausgewerteten Quellen: KI funktioniert als Co-Pilot, nicht als Ersatz. Die Entscheidungsposition bleibt beim Menschen. Die KI liefert Vorschläge, Daten und Entwürfe, die geprüft, korrigiert oder verworfen werden können.

Praxisbeleg

Eine Befragung von rund 2.000 Entwickler*innen (Ziegler et al., Microsoft/GitHub, 2022) bestätigt diesen Co-Pilot-Charakter empirisch: Der berichtete Produktivitätsgewinn durch GitHub Copilot wird primär auf die Automatisierung repetitiver Aufgaben zurückgeführt, nicht auf den Ersatz eigener Entscheidungen.

Praxisbeispiel: Mobile Testautomatisierung

Der Wechsel von einem klassifikationsbasierten zu einem generativen, intentionsbasierten KI-Ansatz für automatisiertes mobiles End-to-End-Testing (unter Nutzung von GPT-4o) steigerte in einer dokumentierten Produktivumgebung die Erfolgsquote der Testläufe auf 91,6% (iOS) bzw. 92,2% (Android) bei über 1.000 automatisierten Tests in laufenden CI/CD-Pipelines. Die Einarbeitungszeit für neue Testfälle sank von 96–120 Stunden auf unter 4 Stunden.

Spezifikationsbindung entscheidet über Testqualität

Eine kontrollierte Studie zeigt: Wird der von der KI selbst generierte Test explizit an eine Spezifikation statt nur an den Code gebunden, liefert der anschließende Reparaturzyklus in 38 Prozentpunkten mehr Fällen tatsächlich korrekten Code, bei einer Falsch-Alarm-Rate von 0% statt 33% ohne diese Bindung. Eine unabhängige Replikationsstudie relativiert dabei gängige Qualitätsmetriken: Code-Abdeckung und Mutationsscore sagen bei KI-generierten Tests kaum etwas über die tatsächliche Fehlererkennung aus, sobald der zu testende Code selbst schon fehlerhaft sein könnte.

Als Assistent für Testende

Konkret bedeutet das etwa: KI generiert innerhalb weniger Minuten eine größere Zahl an Testideen, die Testende anschließend bewerten und ergänzen, nicht um sie eins zu eins zu übernehmen, sondern um den eigenen Denkprozess anzustoßen. Ebenso lassen sich Sprint-Storys, Pull Requests und bestehende Tests durch KI automatisiert verknüpfen, um eine erste Risikoeinschätzung vorzubereiten. Wichtig dabei: Die zugrunde liegenden Rohdaten sollten immer mitgeliefert werden, damit sich die Entscheidungen der KI nachvollziehen und bei Bedarf korrigieren lassen.

Für die repetitive Arbeit

KI übernimmt Routineaufgaben wie die Wartung bestehender Testskripte oder erste Entwürfe von Testdokumentation, damit sich Testende auf exploratives Testen und kritisches Denken konzentrieren können. Das sind die Aufgaben, die menschliche Erfahrung nach wie vor am besten abdeckt.

Automatisierung von API- und Unit-Tests

Dieser Bereich gilt als besonders geeignet für KI-Unterstützung, weil Ergebnisse hier meist deterministisch und klar strukturiert sind. Das ist ein Umfeld, in dem KI-generierter Code zuverlässig funktioniert und sich gut überprüfen lässt.

Mustererkennungs-Tests (Bildvergleich)

KI-gestütztes visuelles Testen vergleicht nicht mehr Pixel für Pixel, sondern erkennt über Bilderkennung, ob eine optische Änderung tatsächlich relevant ist. Eine reale Einschränkung bleibt: Harmlose Unterschiede wie Schriftrendering oder minimale Layoutverschiebungen lösen weiterhin Fehlalarme aus, und die Modelle brauchen vielfältige Trainingsdaten über Auflösungen und Sprachen hinweg. Eine menschliche Prüfung der gemeldeten Abweichungen bleibt deshalb Teil des Prozesses. Eine aktuelle Benchmark-Studie zu dieser Fragestellung bestätigt den Unterschied: Reiner Pixelvergleich stuft harmlose Änderungen praktisch nie korrekt als irrelevant ein, während trainierte Modelle zur Bilderkennung deutlich selektiver zwischen Rauschen und echter Regression unterscheiden. Die sprachliche Beschreibung der erkannten Unterschiede bleibt in der Qualität aber noch deutlich hinter menschlicher Beschreibung zurück.

Abschnittsweiser statt durchgehender Einsatz

Autonome, selbstständig explorierende Test-Agenten werden intensiv beworben, gelten in der aktuellen Forschung aber noch als fragil, rechenintensiv und ohne echtes Verständnis für den Kontext der geprüften Anwendung. Ein treffendes Bild dafür: Sie verhalten sich wie energiegeladene, aber unerfahrene neue Kolleg*innen, schnell, neugierig, aber auf Anleitung angewiesen. Unbeaufsichtigt erzeugen sie eher Rauschen als verlässliche Ergebnisse. Empfehlung: KI in klar abgegrenzten Abschnitten des Testprozesses einsetzen und dort gezielt prüfen, statt sie durchgehend unbeaufsichtigt laufen zu lassen.

Neue Anforderungen an Testengineers

Prompt Engineering als Skill-Transformation

Das präzise Anleiten der KI für zielführende Ergebnisse wird zur Kernkompetenz in der Qualitätssicherung. Ergänzend dazu wird KI-Literacy wichtig: das Verständnis von Annahmen, Verzerrungen und Grenzen der eingesetzten Modelle, ähnlich bedeutsam, wie es die Beherrschung einer Testautomatisierungs-Syntax heute schon ist.

Kontinuierliche Überwachung

Da KI-generierte Tests keinem festen, vorhersagbaren Protokoll folgen, ersetzt eine einmalige Prüfung keine laufende Kontrolle. Automatisierte Fehlermeldungen, Reports und Kennzahlen sollten regelmäßig ausgewertet werden. Menschen bleiben dabei „in the loop“: Sie validieren, hinterfragen und verfeinern, was die KI vorschlägt, statt Ergebnisse unbesehen zu übernehmen.

Konzeptioneller Rahmen für Overreliance

Eine 2026 vorgestellte Arbeit systematisiert, wie sich Übervertrauen in KI-Testagenten zeigt, und unterscheidet dabei drei Ausprägungen: Vertrauen in die falschen Testziele, in unzureichend geprüfte Evidenz und in unbeaufsichtigt delegierte Teilaufgaben. Der Kernbefund: Je autonomer Testagenten werden, desto mehr verschiebt sich die Rolle von Testenden vom eigenständigen Testdesign zur bloßen Aufsicht, mit dem Risiko, dass Testartefakte als Beleg akzeptiert werden, ohne dass die zugrunde liegende Begründung geprüft wird. Eine solche Taxonomie eignet sich als Checkliste, um bei der Einführung von Testagenten gezielt zu prüfen, an welcher Stelle blindes Vertrauen entsteht.

Klare Definition, wo und wie KI angewendet werden soll

Bevor KI eingeführt wird, muss im Team feststehen, was „gute Qualität“ überhaupt bedeutet. Fehlt dieser Konsens, verstärkt KI bestehende Schwächen in der Teststrategie, statt sie zu beheben. In der Praxis bewährt sich ein schrittweises Vorgehen: klare Ziele setzen, mit einem einzelnen, fehleranfälligen Teilbereich beginnen, Erfahrungen sammeln und erst danach erweitern, statt KI von Beginn an flächendeckend einzuführen.

Die Tool-Frage: Welche KI für welchen Zweck?

Test-Framework bzw. Testmanagement-Tool mit integrierter KI

Lösungen wie TestComplete, aqua cloud oder BrowserStack sowie spezialisierte Plattformen wie Katalon Studio, Tricentis Tosca, Mabl, Testim, Functionize, Sauce Labs oder Applitools bringen KI-Funktionen mit, die auf einen konkreten Anwendungsfall zugeschnitten sind, etwa Applitools für visuelles Testen oder Sauce Labs für die Analyse instabiler Tests. Das lässt sich meist nahtlos in bestehende Testprozesse und CI/CD-Pipelines integrieren, bringt aber zusätzliche Lizenzkosten und die Einarbeitung in ein weiteres Tool mit sich.

Bestehende Allzweck-KI (z. B. Claude, Copilot)

Sofort verfügbar und flexibel einsetzbar für Prompting, Testfall-Entwürfe oder Dokumentation, ohne dass ein zusätzliches Tool eingeführt werden muss. Dem stehen fehlende native Anbindung an Testmanagement und CI/CD, die separat zu klärende Datenschutzfrage sowie eine Ergebnisqualität gegenüber, die stark vom mitgelieferten Kontext abhängt.

Modellwahl innerhalb der Allzweck-KI

Auch innerhalb dieser Kategorie gibt es Unterschiede: In der oben genannten JUnit-Studie schnitten die code-spezialisierten Modelle Codex und StarCoder bei der Testgenerierung durchgehend besser ab als das dialogorientierte GPT-3.5-Turbo. Für Testautomatisierung spricht das tendenziell für code-spezialisierte statt allgemeine Dialog-Modelle, ein Kriterium, das bei der Tool- bzw. Modellauswahl mitberücksichtigt werden sollte.

Hybride Ansätze schlagen reine LLM-Generierung

Ein Vergleich zeigt: Direkte Testgenerierung durch LLMs erreichte in einer Studie nur 51–78% kompilierbare Tests, während ein klassisches durchsuchungsbasiertes Verfahren (Search-Based Software Testing, hier EvoSuite) 100% kompilierbaren, aber schwer lesbaren Code lieferte. Ein Ansatz, der LLMs als nachgelagerte Refactoring-Schicht über SBST-generiertem Code einsetzt, erreichte dagegen 88–98% Kompilierbarkeit bei deutlich höherer Lesbarkeit. Für die Tool-Auswahl heißt das: LLMs bringen oft mehr, wenn sie etablierte Verfahren veredeln, als wenn sie allein als Testgenerator eingesetzt werden.

Aktive Prüfagenten schlagen passive LLM-Bewertung

Eine Studie zu drei verbreiteten LLM-Agenten-Frameworks vergleicht einen aktiv testenden, agentbasierten Ansatz mit passiven LLM-als-Richter-Verfahren: Der agentbasierte Ansatz fand 40 zuvor unbekannte Fehler, während sämtliche passiven Vergleichsverfahren keinen einzigen fanden. Dabei erreichte er eine Präzision von 91,2%, gegenüber 29,3% beim besten passiven Verfahren. Das spricht dafür, bei der Tool-Auswahl gezielt zwischen einfacher KI-Bewertung und aktiv explorierenden Testagenten zu unterscheiden: Letztere liefern belastbarere Ergebnisse, sind aber aufwendiger zu betreiben.

Eigene KI (unternehmenseigenes Modell)

Ein eigenes Modell mit unternehmenseigenen Daten zu trainieren, ist mit erheblichem Initialaufwand verbunden. Allein das Training eines mittelgroßen Sprachmodells wie GPT-3 wird auf 500.000 bis 4,6 Millionen US-Dollar geschätzt. Für die meisten Organisationen ist ein vollständiges Eigentraining damit unrealistisch. Realistischer ist das Anreichern bestehender Modelle mit unternehmensspezifischem Kontext, etwa über Prompting mit internen Vorgaben oder den gezielten Abruf bestehender Testartefakte, statt eines vollständigen Neutrainings.

Kombination unterschiedlicher KI-Anbieter je nach Einsatzzweck

In der Praxis bewährt sich häufig kein einzelnes Tool für alle Zwecke, sondern eine Kombination: spezialisierte Werkzeuge für visuelles Testen oder Log-Analyse, ein Testmanagement-Tool mit integriertem Copilot für die Testfallgenerierung und eine Allzweck-KI für Dokumentation und Testideen. Diese Kombination erhöht allerdings auch die Zahl an Schnittstellen und Datenschutz-Verantwortlichkeiten, die geklärt sein müssen, bevor der produktive Einsatz beginnt.

Fazit

Der Mehrwert von KI im Software-Testing entsteht nicht durch unbeaufsichtigten, durchgehenden Einsatz, sondern durch klar abgegrenzte Anwendungsfälle mit definierter menschlicher Kontrolle. Das betrifft die eingesetzten Tools ebenso wie die Kompetenzen im Testteam: Ohne Klarheit darüber, was gute Qualität bedeutet, ohne Prompt-Kompetenz und ohne laufende Überwachung bleibt KI im Testing ein Risiko, kein verlässlicher Vorteil.

Genau an dieser Schnittstelle setzt auch unser eigenes Test-Framework QABridge an. Im nächsten Beitrag dieser Serie zeigen wir konkret, wie sich KI-Unterstützung darin einsetzen lässt und wo dabei die in diesem Beitrag beschriebenen Grenzen zu beachten sind.

Sie stehen vor der Frage, wie viel KI-Einsatz für Ihr Testteam sinnvoll ist und welches Tool dafür infrage kommt? In einem unverbindlichen Austausch schauen wir gemeinsam darauf, wo Grenzen und Chancen in Ihrem konkreten Projekt liegen.

Kontaktieren Sie uns unter: office@gruener-it.at