Der Einsatz von Sprachmodellen beim Softwaretesten bedeutet, KI auf bestimmte, abgegrenzte Aufgaben anzuwenden, bei denen Sprache ohnehin schon das Ausgangsmaterial ist: Testdokumentation erstellen, die Umsetzung von Schlüsselwörtern anhand definierter Regeln überprüfen, technische Fehlermeldungen in einfache Sprache übersetzen und alternative Texte für die Prüfung der Zugänglichkeit identifizieren. Kleinere, klar definierte Aufgaben liefern zuverlässige Ergebnisse. Schlussfolgerungsmodelle schneiden bei regelbasierten Review-Aufgaben besser ab als Standard-Chat-Modelle.
Das Wichtigste in Kürze
- Schlussfolgerungsmodelle schneiden bei Code-Review-Aufgaben besser ab als Standard-Chat-Modelle: Erst der Wechsel von GPT-4o zu O1 hat dazu geführt, dass die automatisierte Keyword-Prüfung brauchbare Ergebnisse lieferte.
- Kleine, eng gefasste KI-Funktionen lassen sich schneller einführen als große End-to-End-Automatisierungen, da Tester die Ausgabe überprüfen können und die Kontrolle über den Prozess behalten.
- Selbstheilende Testautomatisierung, die Embeddings nutzt, um fehlerhafte Locators zu reparieren, birgt das Risiko, echte Fehlerzustände zu verschleiern, da das System eine versehentliche Änderung nicht von einer beabsichtigten unterscheiden kann.
- Da KI-Agenten immer autonomer werden und ohne menschliches Eingreifen zwischen den einzelnen Schritten arbeiten, steigen die Qualitätsanforderungen an ihre Ergebnisse stark an, was die Lücke zwischen dem Einsatz von KI und dem Testen von KI schließt.
Fang mit kleinen Funktionen an, nicht mit einem allgemeinen Testmodell
Die höchste Zuverlässigkeit beim Einbinden von Sprachmodellen in das Testen erreicht man, indem man eng gefasste, klar definierte Probleme löst, anstatt ein einziges Allzweck-Testmodell zu entwickeln. Klaudia Dussa-Zieger und ihr Team sind bewusst diesen Weg gegangen: Anstelle eines fein abgestimmten allgemeinen Test-LLM haben sie kleine Funktionen entwickelt, die dem Nutzer jeweils bei einer einzigen, konkreten Aufgabe helfen.
Dieser Ansatz ist wichtiger als die Wahl des Tools. Wenn du genau weißt, welches Problem du lösen willst, kannst du das richtige Modell auswählen, den richtigen Kontext eingeben und das Ergebnis beurteilen. Wenn du von der Prämisse „Wir müssen KI einsetzen“ ausgehst, bekommst du vage Pilotprojekte, die nie zum Ziel führen.
Die eigene Geschichte des Teams zeigt, wie früh einige dieser Entwicklungen begannen. Ihre ersten KI-Experimente stammen aus dem Jahr 2019, als sie einen Algorithmus zur visuellen Klassifizierung nutzten, um sich bewegende Objekte auf der Benutzeroberfläche zu erkennen. Das war, bevor generative Modelle in ihre Arbeit Einzug hielten. Die Anwendungen mit Sprachmodellen kamen später, angeregt durch eine einfache Beobachtung: Testen basiert auf Text – auf Spezifikationen, Testskripten und Berichten.
Testspezifikationen funktionieren am besten als Entwurf, nicht als fertiges Produkt
Ein LLM sollte einem Tester einen ersten Entwurf liefern, kein endgültiges Ergebnis. Klaudias erster größerer Prototyp leitete Testspezifikationen aus Anforderungen ab, indem er einen RAG-Ansatz (Retrieval-Augmented Generation) nutzte und projektspezifische Informationen in ein generisches Modell einspeiste. Zunächst wurden die Modelle Llama 3.1 und später Claude 3.5 verwendet.
Die erste Version durchlief einen kompletten Zyklus ohne menschliches Eingreifen. Es funktionierte, aber nicht gut. Das Ziel war nie die vollständige Automatisierung. Es ging darum, die leere Seite zu beseitigen, damit ein Tester mit einem Entwurf statt mit einem leeren Dokument beginnt.
Die Tester in diesem Unternehmen reagierten stärker als erwartet. Sie fühlten sich aus einem Prozess ausgeschlossen, der ihr Handwerk betraf. Die Lösung erfüllte gleich zwei Ziele: Sie verbesserte die Qualität und bezog die Tester mit ein, indem sie ihnen eine Plattform bot, auf der sie ihre eigenen Erfahrungen und Informationen einbringen konnten. Dieser Input hat echten Wert, und ein System, das ihn ignoriert, verliert sowohl an Qualität als auch an Vertrauen.
Schlüsselwörter dokumentieren: ein Knopfdruck, einheitlichere Ausgabe
Die automatische Dokumentation von Schlüsselwörtern ist eine kleine Funktion, die sich schnell auszahlt. Im Testmanagementwerkzeug des Teams definieren die Tester Tests mithilfe von Schlüsselwörtern, die im Grunde Code sind – also ein automatisiertes Skript. Wie die meisten Programmierer mögen sie es nicht, Dokumentation zu schreiben.
Die Lösung war ein einziger Knopf. Er liest die Implementierung eines Schlüsselworts aus und erstellt eine Überschrift, eine Beschreibung der Parameter sowie eine ausführlichere Beschreibung der Funktion des Schlüsselworts. Der Tester drückt den Knopf, liest das Ergebnis und ist fertig.
Der Gewinn ging über die Geschwindigkeit hinaus. Da nun alle dieselbe Funktion nutzen, wurden die Beschreibungen im gesamten Team einheitlicher. Konsistenz, nicht nur Bequemlichkeit, erwies sich als der bleibende Vorteil.
Warum Reviews nur mit Argumentationsmodellen funktionierten
Die automatisierte Überprüfung von Schlüsselwort-Implementierungen war mit Standard-Chat-Modellen fehlgeschlagen und gelang nur mit einem Schlussfolgerungsmodell. Das ist die wichtigste Erkenntnis aus der Arbeit des Teams: Der Modelltyp – nicht nur der Zugriff auf das Modell – entscheidet darüber, ob ein Anwendungsfall funktioniert.
Im Rahmen der Einrichtung wurden die Regeln des Teams für die Implementierung von Schlüsselwörtern sowie ein Glossar mit zulässigen Begriffen als zusätzlicher Kontext in das Modell eingespeist. Frühe Versuche mit ChatGPT-4o lieferten keine ausreichend guten Ergebnisse. Der Wechsel zu einem Schlussfolgerungsmodell, O1, machte den Unterschied.
Die funktionierende Version erkennt die meisten offensichtlichen Probleme innerhalb von ein oder zwei Sekunden. Tester führen in der Regel zwei oder drei Durchläufe durch, bis das Schlüsselwort formal einwandfrei aussieht; danach reviewen die Automatisierungsingenieure die Logik. Die mit der Review-Arbeit betrauten Entwickler begrüßten das aus einem praktischen Grund: Es beseitigte den mühsamen, routinemäßigen Teil der Review-Arbeit, sodass sie sich auf die interessanten Probleme konzentrieren konnten.
Diese Aufteilung solltest du im Hinterkopf behalten, wenn du deine eigenen Funktionen planst.
| Funktion | Verwendeter Modelltyp |
|---|---|
| Schlüsselwortdokumentation | Standardmodell |
| Review des Schlüsselworts anhand von Regeln und Glossar | Schlussfolgerungsmodell (O1) |
Es wird keine generische Lösung geben, die alles abdeckt. Unterschiedliche Aufgaben erfordern unterschiedliche Fähigkeiten, und die Abstimmung beider Aspekte ist Teil der Entwurfsarbeit.
Technische Fehlerzustände in eine Sprache übersetzen, die ein Domänentester versteht
Ein LLM kann einen technischen Fehlerzustand in eine Beschreibung umwandeln, die ein Domänenbenutzer lesen kann. Vorhergesehene Fehlhandlungen enthalten meist eine freundliche Meldung, aber eine echte Fehlerwirkung liefert etwas Unverständliches und schwer zu analysierendes. Domänentester können oft nicht erkennen, was das bedeutet.
Die Funktion des Teams speist den Fehlerzustand zusammen mit dem Testfall, der ihn ausgelöst hat, in ein LLM ein, das eine Erklärung in einfacher Sprache zurückgibt. Das ist ein weiteres Übersetzungsproblem, und Sprache ist genau das, was diese Modelle gut beherrschen. Es hat reibungslos funktioniert.
Unterstützung beim täglichen Programmieren ist bereits Routine
Der Einsatz von KI beim Programmieren und beim Einrichten der Entwicklungsumgebung ist im Team still und leise zur Normalität geworden. Kollegen nutzen Copilot zum Programmieren, ohne das als etwas Besonderes zu betrachten. Ein Entwickler nutzt es außerdem, um Vagrant-Skripte zu schreiben, die die Testumgebung automatisch einrichten – was gut zu einem DevOps-Ansatz passt, bei dem die Umgebung per Code erstellt wird.
Das von ihm beschriebene Vorgehen ist nachahmenswert. Das generierte Skript bringt ihn zu etwa 95 Prozent ans Ziel – ein Standardergebnis, das er in Sekundenschnelle erhält. Die letzten fünf Prozent erledigt er selbst, da er weiß, wie das Skript aussehen sollte, und es schnell überprüfen kann. Was sonst fünfzehn Minuten bis eine halbe Stunde dauern würde, wird so zu einem schnellen Entwurf plus einer Review.
Der Mensch im Kreislauf beschleunigt Tests zur Zugänglichkeit, macht sie aber nicht autonom
Du brauchst kein perfektes Ergebnis, solange ein qualifizierter Gutachter im Kreislauf bleibt. Das Team testete dies im Bereich der digitalen Zugänglichkeit – einem Bereich, von dem lange angenommen wurde, dass die Automatisierungsrate bei etwa 40 Prozent ihre Obergrenze erreicht, da ein Mensch beurteilen muss, ob Text akzeptabel ist.
Sie haben es trotzdem versucht und dabei ein Agent-Setup mit MCP genutzt, um Alternativtext für Bilder zu generieren – also in Fällen, in denen ein Bild interpretiert werden muss. Es hat funktioniert, wenn auch nicht perfekt. Manchmal schlägt das System Alternativtext vor, den der Spezialist als Duplikat ablehnen würde, das keinen zusätzlichen Sinn ergibt.
Der Vorteil liegt in der Geschwindigkeit, nicht in der Autonomie. Das System durchläuft alle Bilder schnell, und der Mensch führt für jedes Ergebnis eine Review durch und entscheidet, ob es stichhaltig ist. Diese Arbeitsteilung ist heute das realistische Modell für viele Testaufgaben.
Wo LLMs noch versagen: Reverse Engineering von eingebettetem Code
Manche Testaufgaben gehen über die aktuellen Modelle hinaus, und das Reverse Engineering von altem eingebettetem Code ist ein klares Beispiel dafür. Zwei Projekte schreiben aus regulatorischen Gründen Unit-Tests für bestehenden C-Code – eine Arbeit, die der Archäologie ähnelt: Man gräbt sich durch schlecht dokumentierten Code ohne Anforderungen und rekonstruiert die Bedeutung allein anhand des Quellcodes.
Auf die direkte Frage, ob ein LLM helfen könnte, antwortete der KI-Experte des Teams mit Nein. Die Teams wollen keine Line-Coverage-Tests. Sie wollen Testfälle, die Sinn ergeben, und dieses Verständnis fehlt noch. Einen Schlüsselwort-Header zu schreiben oder anhand von Regeln zu prüfen, ist eine Sache. Sich auf undokumentierten Legacy-Code zu konzentrieren, um aussagekräftige Tests zu schreiben, ist eine andere.
Seine Meinung war unverblümt: Um dieses Niveau zu erreichen, wären erhebliche Investitionen in das Training oder die Anpassung der Modelle nötig – und bis dahin kann ein kleines Team die Arbeit selbst erledigen.
Testautomatisierung auf höherer Ebene: teilweise hilfreich, gemischte Ergebnisse
Bei der Testautomatisierung reicht die Unterstützung durch LLMs je nach Ebene von solide bis ungelöst. Automatisierung ist Programmierung, daher funktioniert die Codierungshilfe im Copilot-Stil hier genauso gut wie bei der normalen Entwicklung.
Auf Systemebene kann KI über die grafische Benutzungsschnittstelle dabei helfen, Objekte zu erkennen, die sich bewegen oder leicht umbenannt werden. Wort-Embeddings aus LLMs wurden genutzt, um alternative Locators zu finden, wenn der erste nicht mehr funktioniert – was in Richtung selbstheilender Testfälle weist.
Selbstheilung birgt ein echtes Risiko. Wenn Einbettungen defekte Lokatoren stillschweigend reparieren, können sie echte Fehlerzustände verschleiern, und es wird schwierig, eine zufällige Änderung von einem echten Fehlerzustand zu unterscheiden, der Aufmerksamkeit verdient. Ein Vortrag zu dieser Idee auf der RoboCon 2025 wurde im folgenden Jahr nicht weiterverfolgt. Die Richtung ist offen, nicht bewiesen.
Kapazitäten für die Merkmale freimachen, die als Erstes wegfallen
Der größte Wunsch an KI im Testbereich ist Schnelligkeit bei Routineaufgaben, damit Tester ihre Aufmerksamkeit dort einsetzen können, wo die Qualität normalerweise leidet. Unter Zeitdruck stehen funktionale Tests an erster Stelle. Leistung und IT-Sicherheit folgen. Die Gebrauchstauglichkeit ist das erste Merkmal, das wegfällt, wenn die Zeit knapp wird.
Wenn KI die routinemäßigen funktionalen Tests schnell genug abarbeitet, können Teams die Aspekte der Qualität schützen, die normalerweise vernachlässigt werden. Die Testberichterstattung ist ein weiterer naheliegender Anwendungsbereich, da das Zusammenfassen von Informationen in Text genau das ist, was ein Sprachmodell gut kann – und das Verfassen dieser Zusammenfassung ist eine Aufgabe, die viele Tester lieber abgeben würden.
KI-Einsatz und das Testen von KI nähern sich wieder an
Die Kluft zwischen dem Einsatz von KI zum Testen und dem Testen von KI selbst schließt sich, je autonomer die Systeme werden. Lange Zeit schienen dies zwei getrennte Bereiche zu sein, bei denen immer ein Mensch zwischen dem Modell und dem nächsten Schritt stand.
Autonomie verändert die Gleichung. MCP, das Model Context Protocol, wurde im November 2024 veröffentlicht, und damit steigt die Zahl der Agenten, die eigenständig arbeiten. Je mehr Autonomie ein Agent erhält, desto besser muss seine Ausgabe sein, denn es gibt keinen Menschen dazwischen, der ein schwaches Ergebnis vor dem nächsten Verarbeitungsschritt abfängt.
Ich glaube, mit dem Aufkommen autonomerer Systeme schließt sich die Lücke zwischen dem Einsatz von KI und dem Testen von KI wieder, denn je mehr Autonomie man einem KI-Agenten gibt, desto besser muss er sein. — Klaudia Dussa-Zieger
Dieser Wandel macht Autonomie zu einer Frage des Testens. Die Entscheidung, wie viel Freiheit man einem System einräumt, ist eine risikobasierte Entscheidung – dieselbe Logik, die das Testen schon immer bestimmt hat. Ein autonomer Agent, der Termine bucht oder Geld überweist, benötigt Zugriff auf deine Bank- und Gesundheitsdaten, und die Anforderungen an den Zugriff, den solche Agenten benötigen, sind Grund genug, sie gründlich zu testen. Da sich Agent-Farmen und koordinierte Teams immer weiter verbreiten, wird die Qualität der einzelnen Agenten zum entscheidenden Faktor.
