KI im Software-Testing: Wo sie heute schon wirkt

10. Aug.

8 Min. Lesezeit

Aktualisiert: 19. Aug.

Beitragsbild 'Wo KI heute schon wirkt': Checkliste bereits produktiv genutzter KI-Anwendungen im Software-Testing, Grüner IT.

Kaum ein Testtool wird derzeit noch ohne „KI-Feature“ beworben. Gleichzeitig kursieren Schlagzeilen über autonome KI-Agenten, die angeblich ganze Testsuiten selbstständig entwerfen, ausführen und pflegen.

Zwischen Marketing-Versprechen und tatsächlichem Nutzen liegt der Alltag der Softwareentwicklung. Dort hat sich Künstliche Intelligenz in den vergangenen Jahren in mehreren, klar abgegrenzten Testaktivitäten etabliert, während andere Ideen sich bislang nur im Forschungsstadium befinden oder reine Ankündigungen sind.

Dieser Beitrag konzentriert sich auf den ersten Teil: auf die Einsatzfelder, in denen KI im Software-Testing heute nachweislich produktiv genutzt wird: von der Prüfung von User-Storys über Testdaten und Testfälle bis zur Fehleranalyse. Die Grenzen, Risiken und organisatorischen Voraussetzungen dieses Einsatzes behandeln wir in einem eigenen, weiterführenden Beitrag.

Beginnen wir beim ersten Einstiegspunkt im Software-Testing, noch bevor der Test tatsächlich startet.

DoD-Verifikation und Anforderungsanalyse

Bevor überhaupt ein Testfall entsteht, muss eine User-Story testbar formuliert sein: klare Vorbedingung, Aktion, erwartetes Ergebnis. Genau hier setzt ein vielversprechender, aber noch vergleichsweise junger KI-Einsatzfall an: die automatisierte Analyse von Anforderungen und Akzeptanzkriterien. Er hängt stark von den erst seit kurzer Zeit zuverlässigen Sprachverständnis-Fähigkeiten moderner Sprachmodelle ab und ist bislang weniger breit etabliert als die anderen in diesem Beitrag beschriebenen Einsatzfelder. Dieser Teil hat per se nichts mit Software-Testing zu tun, dennoch ist es ein essenzieller Bestandteil davon, da die Testenden bzw. die KI in weiterer Folge aus den Akzeptanzkriterien Testfälle ableiten sollen.

Ein anschauliches Beispiel, wie das aussehen kann, beschreibt das Bundesrechenzentrum (BRZ) in seinem Blog: Eine KI analysiert eine technische Spezifikation und schlägt innerhalb weniger Minuten eine vollständige Suite von Testfällen vor. Ein Prozess, der zuvor Tage an Anforderungsanalyse gebraucht hätte, ist damit auf wenige Minuten verkürzt. Der Entwurf wird anschließend von einer Testperson geprüft und die Logik verfeinert; die KI ersetzt diesen Schritt nicht, sie beschleunigt ihn massiv. Das BRZ beschreibt dieses Szenario als Illustration des Prinzips und bestätigt darüber hinaus allgemein, KI bereits erfolgreich in der eigenen Testautomatisierung einzusetzen.

Damit lässt sich auch die Definition of Ready systematischer absichern: Fehlen die Akzeptanzkriterien oder lässt sich ein Akzeptanzkriterium von der KI nicht in einen prüfbaren Testschritt übersetzen, ist das ein früher Hinweis auf eine unklare oder unvollständige Anforderung. Testende können diesen Punkt gezielt ansprechen, bevor die Implementierung beginnt.

Testdaten-Generierung

Synthetische Testdatengenerierung gehört zu den technisch am weitesten entwickelten KI-Anwendungen im Software-Testing. Dedizierte Anbieter dafür gibt es bereits seit Jahren, deutlich vor dem aktuellen Sprachmodell-Boom, nicht zuletzt getrieben durch den Anonymisierungsbedarf im Zuge der DSGVO. Sie ist besonders dort wertvoll, wo reale Daten aus Datenschutzgründen nicht verwendet werden dürfen oder schlicht nicht in ausreichender Vielfalt vorliegen, etwa bei Finanz- oder Gesundheitsdaten.

KI kann dabei über Mustererkennung Datensätze erzeugen, die sich strukturell wie echte Nutzungsdaten verhalten, ohne einen Bezug zu realen Personen zu haben. Anwendungsfälle reichen von der Simulation realistischer Lastszenarien (z. B. tausende gleichzeitige Transaktionen) über die Nachbildung von Nutzerverhalten in Bestellprozessen bis zur automatisierten Erstellung von Testfällen für unterschiedliche Sprachversionen.

Eine reale Einschränkung bleibt: Synthetische Daten spiegeln ohne gezielte Steuerung meist „durchschnittliche“ oder unauffällige Fälle wider. Seltene Kombinationen und echte Randfälle, die reale Nutzung prägen, werden dabei leicht unterrepräsentiert. In der Praxis bewährt sich deshalb eine Kombination: synthetische Daten für Umfang und Skalierung, ergänzt um anonymisierte reale Daten, um Tests an tatsächlicher Nutzungskomplexität zu verankern.

Strategien wie Subsetting, Data Masking und Golden Dataset, die wir im letzten Beitrag zu Testdaten und Testumgebungen vorgestellt haben, lassen sich mit KI-gestützter Generierung gut kombinieren, statt sie zu ersetzen.

Testfall-Generierung: von der Spezifikation zum Testfall

Die Generierung von Testfällen aus Anforderungen in normaler Sprache (nicht in formaler Programmiersprache) ist heute das KI-Flaggschiff-Feature praktisch jedes Testtool-Anbieters, vor allem seit dem Sprachmodell-Boom der vergangenen Jahre, und dadurch eine der am breitesten verfügbaren KI-Anwendungen im Software-Testing. Sie funktioniert besonders zuverlässig, wenn Anforderungen klar strukturiert und möglichst eindeutig formuliert sind; eine Überprüfung durch Testende bleibt aber notwendig. Ein praktischer Zusatznutzen: KI schlägt gezielt Rand- und Negativfälle vor (etwa leere Pflichtfelder, fehlerhafte Formate oder ungewöhnliche Kombinationen), die in einer manuellen Testfallerstellung leicht übersehen werden.

BDD (Behavior Driven Development)

Auf Basis von in normaler Sprache formulierten Beschreibungen erzeugt KI strukturierte Given-When-Then-Szenarien. Das senkt die Einstiegshürde für Fachbereich und Product Owner*in, eigene Testszenarien in einer für alle verständlichen Sprache beizusteuern, statt sie ausschließlich technisch formulieren zu müssen.

TDD (Test Driven Development)

Arbeitet die Entwicklung testgetrieben, kann KI auf Basis der Funktionssignatur oder des Docstrings ein erstes Gerüst für den zugehörigen Unit-Test entwerfen. Die eigentliche fachliche Aussage des Tests – also welche Bedingungen und Assertions tatsächlich relevant sind – bleibt weiterhin Aufgabe der Entwicklung.

DDT (Data Driven Testing)

Hier verbindet sich Testfall- und Testdatengenerierung direkt: Die Testlogik bleibt fix, die KI generiert die passenden Datenvariationen dazu und erweitert so die Abdeckung, ohne dass jede Zeile einer Datentabelle manuell angelegt werden muss.

Model-Based Testing (MBT)

Statt Testfälle direkt aus Prosa-Anforderungen zu schreiben, leitet die KI aus der Spezifikation ein formales Modell des Systemverhaltens ab (etwa ein Zustandsdiagramm oder eine Entscheidungstabelle) und generiert daraus automatisiert Testfälle, die alle relevanten Zustände und Übergänge abdecken. Das reduziert den manuellen Übersetzungsaufwand von Anforderung zu Testfall erheblich, setzt aber eine Spezifikation voraus, die präzise genug ist, um ein brauchbares Modell zu erzeugen.

KDT (Keyword Driven Testing)

Testschritte werden aus wiederverwendbaren Schlüsselwörtern zusammengesetzt (z. B. „Login“, „Warenkorb befüllen“), die KI unterstützt bei der Erstellung, Pflege und Erweiterung dieser Bausteine. Das trennt Testlogik von der technischen Umsetzung und macht auch für Nicht-Entwickler*innen nachvollziehbar, was ein Testfall tatsächlich prüft. Das ist eine sinnvolle Ergänzung zur Datenvariation aus DDT.

Weitere Verfahren

Neben den hier vorgestellten Ansätzen gibt es weitere etablierte Verfahren zur Testfall-Generierung, etwa Property-Based Testing oder Combinatorial/Pairwise Testing. Diese behandeln wir in einem eigenen, weiterführenden Beitrag.

Die Qualität des Ergebnisses hängt bei all diesen Verfahren direkt von der Qualität des Inputs ab: Je präziser Kontext, Geschäftslogik und erwartetes Verhalten mitgegeben werden, desto brauchbarer der generierte Testfall. Ohne Review bleibt jeder KI-generierte Testfall ein Entwurf, kein fertiges Ergebnis.

Code-Generierung für die Testautomatisierung

Ein etablierter Anwendungsfall ist die KI-gestützte Umwandlung bereits bestehender manueller Testfälle in ausführbaren Automatisierungscode, etwa in Playwright-, Selenium- oder reine Python-Skripte. Voraussetzung ist, dass die manuellen Schritte klar strukturiert und deterministisch beschrieben sind.

Self-Healing Locators

Das ist eine der praxisreifsten KI-Funktionen in der UI-Automatisierung. Ändert sich ein Element im DOM (Document Object Model, die strukturierte Darstellung einer Webseite im Browser), etwa weil sich eine Button-ID oder CSS-Klasse ändert, erkennt die KI anhand anderer Merkmale wie sichtbarem Text, Position oder Rolle im Layout das wahrscheinlichste Nachfolgeelement und passt den Test automatisch an, statt ihn fehlschlagen zu lassen. Das reduziert Instabilität des Codes und Wartungsaufwand in Regressionssuiten spürbar. Das ist allerdings kein Freibrief: Wird das falsche Element zugeordnet, läuft ein Test grün, obwohl er inhaltlich etwas anderes prüft als beabsichtigt. Gerade bei kritischen Abläufen bleibt deshalb eine stichprobenartige menschliche Kontrolle sinnvoll.

Für belastbare Ergebnisse bei der Code-Generierung hat sich in der Praxis ein Vorgehen bewährt: Kontext liefern (fachlicher Kontext bzw. Geschäftslogik, zu prüfendes Risiko, gewünschte Assertions, verwendete Tool-Version), möglichst konkret und mit Beispielen anfragen, und den generierten Code grundsätzlich testen und reviewen, mit derselben Sorgfalt wie selbst geschriebenen Code.

Empirische Evidenz

Diese Praxisempfehlung deckt sich mit Forschungsergebnissen zur Testgenerierung mit Sprachmodellen: Eine Studie zum Prototyp TestPilot (GitHub Next, Northeastern University u. a., 2023) erzielt für JavaScript-Pakete allein durch Anreicherung des Prompts mit Signatur, Dokumentation und Codebeispielen eine mediane Statement-Coverage von 70,2 %, deutlich mehr als die 51,3 % einer klassischen, KI-freien Testgenerierungstechnik (Nessie) im direkten Vergleich. Wie stark der mitgelieferte Kontext das Ergebnis beeinflusst, zeigt eine Untersuchung zu GitHub Copilot: Mit Kontext (bestehende Tests der Suite bleiben erhalten) waren 45,3 % der generierten Tests lauffähig, ohne Kontext nur 7,6 %.

Reporting und Fehleranalyse

Log-Anomalie-Erkennung

Moderne Systeme erzeugen in Test und Betrieb enorme Logmengen. KI-gestützte, unüberwachte Lernverfahren erkennen darin Abweichungen (neue Fehlerarten, Fehler-Spitzen, Verhaltensänderungen) und sind mittlerweile Standard in Monitoring-Plattformen wie Elastic, Datadog oder Splunk. Für das Software-Testing bedeutet das: Muster für intermittierende Tests und stille Regressionen (Verschlechterung durch Codeänderung, die kein Test bemerkt) werden schneller sichtbar, die Fehler-Triage beschleunigt sich.

LLM-gestützte Log-Zusammenfassung

Große Sprachmodelle können Testlogs zusammenfassen und priorisieren, was die Fehlersuche erleichtert. Der Ansatz ist vielversprechend, aber noch nicht ausgereift: Das Ergebnis reagiert empfindlich auf die Formulierung der Anfrage, Logs enthalten oft systemspezifischen Jargon und Fehlercodes, die ein allgemeines Modell ohne Anpassung schwer einordnen kann, und die Verarbeitung großer Logmengen in Echtzeit ist rechenintensiv.

Reporting

KI-gestützte Auswertungen fassen Testergebnisse zusammen, heben Risiken hervor und übersetzen technische Befunde in eine für Stakeholder*innen verständliche Aussage zur Auswirkung auf das Produkt. Das ergänzt klassische Testberichte um eine unmittelbar geschäftsrelevante Ebene.

Refactoring, Bug-Fixing und Code-Coverage

Risikobasierte Priorisierung

KI stuft Testfälle nach Risiko ein, identifiziert veraltete oder doppelte Skripte und passt Regressionstests an, wenn neue Funktionen hinzukommen. In Kombination mit automatisierter Ursachenanalyse werden Testsuiten dadurch robuster und der Wartungsaufwand sinkt.

Fehlervorhersage anhand historischer Daten

Auf Basis vergangener Bugs und Codeänderungen lassen sich potenziell fehleranfällige Bereiche vorhersagen, um Testaufwand gezielt zu fokussieren. Das ist in der Forschung gut belegt, in der Praxis aber noch schwer umzusetzen: Die Modelle brauchen saubere, konsistente historische Daten, die vielen Teams fehlen, sie generalisieren schlecht zwischen unterschiedlichen Projekten, und komplexere Modelle liefern Vorhersagen ohne nachvollziehbare Begründung. Dieser Ansatz ist aktuell eher experimentell als produktionsreif.

Code-Coverage

KI unterstützt bei der Analyse, wo Testabdeckung fehlt (etwa bei selten durchlaufenen Codepfaden), und schlägt gezielt neue Tests für nicht abgedeckte Bereiche vor, statt Coverage-Berichte nur zu dokumentieren.

Beispiele aus der Praxis

Ein Hinweis zur Einordnung

Die genannten Einsatzfelder sind keine theoretischen Konstrukte. Mehrere Unternehmen haben öffentlich, über technische Blogs oder Forschungspublikationen, offengelegt, wie sie KI-gestütztes Software-Testing produktiv einsetzen. Eine Einordnung vorab: Firmeneigene Engineering-Blogs und Forschungspapers sind belastbarer als Fallstudien, die von Tool-Anbietern selbst veröffentlicht werden. Letztere sind Marketingmaterial und entsprechend mit Vorsicht zu lesen.

Meta (Facebook) – automatisierte Testfall-Generierung

Meta (Facebook) setzt seit September 2017 das Werkzeug Sapienz produktiv ein: eine KI, die über computergestützte Suche (search-based software testing) selbstständig UI-Testfälle für die Android-App entwirft, ausführt und auswertet. Laut Metas eigenem Engineering-Blog erzeugt Sapienz täglich zehntausende Testfälle, wobei 75 Prozent der gemeldeten Probleme tatsächlich zu einer Codekorrektur führten. Das ist ein vergleichsweise niedriger Anteil an Fehlalarmen für ein automatisiertes System dieser Größenordnung

Meta (Facebook) – risikobasierte Testauswahl

Ebenfalls bei Meta im Einsatz ist eine mit klassischen Machine-Learning-Verfahren trainierte Auswahl, welche Tests bei einer Codeänderung überhaupt ausgeführt werden müssen. Die zugehörige Forschungsarbeit wurde im Oktober 2018 als Preprint veröffentlicht und 2019 in überarbeiteter Fassung vorgestellt; nach ihren Angaben senkt das Verfahren die Test-Infrastrukturkosten um die Hälfte, während weiterhin über 95 Prozent der einzelnen Testfehler und über 99,9 Prozent der fehlerhaften Codeänderungen zuverlässig erkannt werden.

Google – Datenbasis für Instabile-Test-Erkennung

Google veröffentlichte bereits 2016 Kennzahlen, die zeigen, wie relevant Fehleranalyse in großem Maßstab ist: rund 16 Prozent der eigenen Tests zeigten irgendeine Form von Flakiness, und 84 Prozent der beobachteten Wechsel von „bestanden“ zu „fehlgeschlagen“ gingen tatsächlich auf instabile statt auf echte Fehler zurück. Diese Datenbasis war der Ausgangspunkt für Googles spätere Arbeit an musterbasierter, teilautomatisierter Erkennung solcher Fehler ohne wiederholten Testlauf.

KPN – visuelles Testen (Kundenreferenz, mit Vorbehalt)

KPN, ein niederländischer Telekommunikationsanbieter, berichtet in einer vom Anbieter Applitools veröffentlichten Kundenreferenz, den visuellen Testlauf über alle Komponenten von zuvor zweieinhalb Stunden auf rund fünf Minuten reduziert zu haben, indem Pull Requests automatisiert gegen eine KI-gestützte visuelle Prüfung laufen. Da es sich um eine vom Tool-Anbieter selbst veröffentlichte Fallstudie handelt, ist dieser Wert als Kundenaussage und nicht als unabhängig geprüfte Kennzahl zu lesen.

Fazit

KI hat sich in mehreren konkreten, klar abgegrenzten Testaktivitäten bewährt: bei der Prüfung von Akzeptanzkriterien, bei synthetischen Testdaten, bei der Generierung von Testfällen und BDD-Szenarien, bei selbstheilendem Automatisierungscode und bei der Fehleranalyse in Logs und Regressionssuiten. Die Praxisbeispiele von Meta und Google zeigen zudem, dass sich dieser Nutzen auch in konkreten Zahlen ausdrücken lässt. Allen Einsatzfeldern gemeinsam ist: Die Qualität des Ergebnisses hängt direkt von der Qualität des Kontexts ab, den man der KI mitgibt. Eine menschliche Prüfung bleibt fester Bestandteil des Prozesses, nicht ein optionaler Zusatzschritt.

Wo genau die Grenzen dieses Einsatzes liegen, welche neuen Anforderungen das an Testengineers stellt und wie sich die passenden Tools auswählen lassen, behandeln wir im weiterführenden Beitrag „KI im Software-Testing: Grenzen, Rollen und die richtige Tool-Wahl“.

Sie überlegen, wo KI in Ihrem Testprozess den größten Hebel bringen könnte? In einem unverbindlichen Austausch schauen wir gemeinsam darauf, welche der hier vorgestellten Ansätze zu Ihrem Projekt passen.

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