LLMs im Testen: Fang mit kleinen, überschaubaren Aufgaben an

LLMs im Testen einzusetzen heißt, KI für klar abgegrenzte Aufgaben zu nutzen, bei denen Sprache ohnehin das Material ist: Testdokumentation erzeugen, Keyword-Implementierungen gegen feste Regeln prüfen, technische Fehlermeldungen in verständliche Sprache übersetzen und Alternativtexte für Barrierefreiheitsprüfungen vorschlagen. Kleine, gut definierte Aufgaben liefern verlässliche Ergebnisse. Bei regelbasierten Reviews schneiden Schlussfolgerungsmodelle besser ab als normale Chatmodelle.

Das Wichtigste in Kürze

• Schlussfolgerungsmodelle (Reasoning-Modelle) schlagen normale Chatmodelle bei Code-Reviews: Erst der Wechsel von GPT-4o zu O1 brachte brauchbare Ergebnisse beim automatischen Review von Keywords.
• Kleine, eng zugeschnittene KI-Funktionen setzen sich schneller durch als große Ende-zu-Ende-Automatisierung, weil Tester die Ergebnisse prüfen können und den Prozess in der Hand behalten.
• Selbstheilende Testautomatisierung, die kaputte Locators per Embeddings repariert, kann echte Fehlerzustände verdecken, weil das System eine versehentliche Änderung nicht von einer beabsichtigten unterscheiden kann.
• Je autonomer KI-Agenten arbeiten, ohne dass zwischen den Schritten ein Mensch prüft, desto höher werden die Qualitätsanforderungen an ihre Ergebnisse. Damit schließt sich die Lücke zwischen KI nutzen und KI testen.

LLMs im Testen: mit kleinen Funktionen anfangen, nicht mit einem Universalmodell

Am zuverlässigsten gelingt der Einsatz von LLMs im Testen, wenn du enge, klar umrissene Probleme löst, statt ein Testmodell für alles zu bauen. Klaudia Dussa-Zieger und ihr Team sind bewusst diesen Weg gegangen: Statt ein allgemeines Test-LLM per Fine-Tuning zu trainieren, haben sie kleine Funktionen gebaut, die jeweils bei genau einer konkreten Aufgabe helfen.

Dieser Zuschnitt zählt mehr als die Wahl des Werkzeugs. Wenn du genau weißt, welches Problem du lösen willst, kannst du das passende Modell wählen, ihm den richtigen Kontext geben und das Ergebnis beurteilen. Wer mit “Wir müssen KI einsetzen” startet, bekommt vage Piloten, die nie ankommen.

Die Geschichte des Teams zeigt, wie früh manches davon begann. Die ersten KI-Experimente stammen aus dem Jahr 2019: Ein visueller Klassifikationsalgorithmus erkannte sich bewegende Objekte auf der Oberfläche. Das war, bevor generative Modelle in die Arbeit kamen. Die Anwendungen mit Sprachmodellen folgten später, ausgelöst von einer einfachen Beobachtung: Testen lebt von Text, von Spezifikationen, Testskripten und Berichten.

Testspezifikationen taugen als Entwurf, nicht als fertiges Produkt

Ein LLM sollte dem Tester einen Entwurf liefern, kein fertiges Artefakt. Klaudias erster größerer Prototyp leitete Testspezifikationen aus Anforderungen ab, mit einem RAG-Ansatz (Retrieval-Augmented Generation), der projektspezifische Informationen in ein generisches Modell einspeiste. Zum Einsatz kamen zuerst Llama 3.1, später Claude 3.5.

Die erste Version lief einen kompletten Zyklus ganz ohne menschliches Eingreifen durch. Das funktionierte, aber nicht gut. Volle Automatisierung war allerdings nie das Ziel. Es ging darum, das leere Blatt abzuschaffen, damit ein Tester mit einem Entwurf beginnt statt mit einem leeren Dokument.

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 zwei Ziele zugleich: Sie verbesserte die Qualität des Ergebnisses und holte die Tester ins Boot, weil sie nun an einer Stelle ihre eigene Erfahrung und ihre Informationen einbringen konnten. Dieser Input hat echten Wert, und ein System, das ihn ignoriert, verliert Qualität und Vertrauen.

Keywords dokumentieren: ein Knopf, einheitlichere Ergebnisse

Keywords automatisch zu dokumentieren ist eine kleine Funktion, die sich schnell auszahlt. Im Testmanagementwerkzeug des Teams spezifizieren Tester ihre Tests mit Keywords, und die sind im Grunde Code, ein automatisiertes Skript. Wie die meisten Programmierer schreiben sie ungern Dokumentation.

Die Lösung war ein einziger Knopf. Er liest die Implementierung eines Keywords und erzeugt einen Header, eine Beschreibung der Parameter und eine längere Beschreibung dessen, was das Keyword tut. Der Tester drückt den Knopf, liest das Ergebnis und ist fertig.

Der Gewinn ging über Tempo hinaus. Weil alle dieselbe Funktion nutzen, wurden die Beschreibungen im Team einheitlicher. Der bleibende Nutzen war Konsistenz, nicht nur Bequemlichkeit.

Warum Reviews nur mit Schlussfolgerungsmodellen funktionierten

Das automatische Review von Keyword-Implementierungen scheiterte mit normalen Chatmodellen und klappte erst mit einem Schlussfolgerungsmodell, auch Reasoning-Modell genannt. Das ist die deutlichste Lehre aus der Arbeit des Teams: Ob ein Anwendungsfall funktioniert, entscheidet die Art des Modells, nicht nur der Zugang zu irgendeinem Modell.

Das Setup gab dem Modell die Regeln des Teams für die Implementierung von Keywords und ein Glossar zulässiger Begriffe als zusätzlichen Kontext mit. Die ersten Versuche mit ChatGPT-4o lieferten keine ausreichend guten Ergebnisse. Den Unterschied machte der Wechsel zum Schlussfolgerungsmodell O1.

Die funktionierende Version findet die meisten offensichtlichen Probleme in ein, zwei Sekunden. Tester lassen typischerweise zwei oder drei Durchläufe laufen, bis das Keyword formal sauber aussieht, danach prüfen die Automatisierungsentwickler die Logik. Die geprüften Entwickler begrüßten das aus einem praktischen Grund: Der mühsame, immer gleiche Teil des Reviews fiel weg, und sie konnten sich auf die interessanten Probleme konzentrieren.

Diese Aufteilung solltest du im Kopf behalten, wenn du eigene Funktionen planst.

Eine generische Lösung für alles wird es nicht geben. Verschiedene Aufgaben brauchen verschiedene Fähigkeiten, und beides zusammenzubringen ist Teil der Designarbeit.

Technische Fehlermeldungen so übersetzen, dass Fachtester sie verstehen

Ein LLM kann eine technische Fehlermeldung in eine Beschreibung übersetzen, die ein Fachanwender lesen kann. Erwartete Fehler bringen meist eine freundliche Meldung mit, ein echter technischer Fehler wirft dagegen etwas Dichtes, schwer Lesbares aus. Fachtester können oft nicht erkennen, was es bedeutet.

Die Funktion des Teams gibt die Fehlermeldung zusammen mit dem auslösenden Testfall an ein LLM, das eine Erklärung in verständlicher Sprache zurückliefert. Auch das ist eine Übersetzungsaufgabe, und mit Sprache kommen diese Modelle gut zurecht. Es funktionierte reibungslos.

Unterstützung beim Programmieren ist längst Alltag

KI beim Programmieren und beim Aufsetzen von Umgebungen zu nutzen, ist im Team still und leise normal geworden. Kollegen arbeiten mit Copilot, ohne daraus etwas Besonderes zu machen. Ein Entwickler lässt sich damit auch Vagrant-Skripte schreiben, die die Testumgebung automatisch aufsetzen. Das passt zu einem DevOps-Ansatz, bei dem die Umgebung aus Code entsteht.

Sein Vorgehen lohnt sich zum Nachmachen. Das generierte Skript bringt ihn auf etwa 95 Prozent, ein Standardergebnis in Sekunden. Die letzten fünf Prozent erledigt er selbst, weil er weiß, wie das Skript aussehen muss, und es schnell prüfen kann. Aus fünfzehn Minuten bis einer halben Stunde Arbeit werden ein schneller Entwurf und ein Review.

Mit menschlicher Prüfung wird das Testen der Barrierefreiheit schneller, nicht autonom

Du brauchst kein perfektes Ergebnis, wenn eine fachkundige Prüferin oder ein fachkundiger Prüfer im Prozess bleibt. Das Team hat das an der digitalen Barrierefreiheit getestet, einem Feld, bei dem man lange annahm, dass bei etwa 40 Prozent Automatisierung Schluss ist, weil ein Mensch beurteilen muss, ob ein Text taugt.

Sie haben es trotzdem versucht, mit einem Agenten-Setup über MCP, das Alternativtexte für Bilder erzeugt. Das ist genau der Fall, bei dem ein Bild interpretiert werden muss. Es funktionierte, wenn auch nicht perfekt. Manchmal schlägt das System einen Alt-Text vor, den die Fachperson ablehnen würde, weil er nur etwas wiederholt und keine Bedeutung hinzufügt.

Der Wert liegt im Tempo, nicht in der Autonomie. Das System arbeitet alle Bilder schnell durch, und der Mensch prüft jedes Ergebnis und entscheidet, ob es trägt. Diese Arbeitsteilung ist heute für viele Testaufgaben das realistische Modell.

Wo LLMs noch scheitern: eingebetteten Legacy-Code zurückentwickeln

Manche Testarbeit übersteigt die heutigen Modelle, und das Reverse Engineering von altem Embedded-Code ist ein klares Beispiel. In zwei Projekten entstehen aus regulatorischen Gründen Unit-Tests für bestehenden C-Code. Die Arbeit gleicht Archäologie: Du gräbst dich in schlecht dokumentierten Code ohne Anforderungen und rekonstruierst die Bedeutung allein aus dem Quelltext.

Auf die direkte Frage, ob ein LLM dabei helfen könne, sagte der KI-Experte des Teams nein. Die Teams wollen keine Tests für die Zeilenabdeckung. Sie wollen Testfälle, die Sinn ergeben, und dieses Verständnis ist nicht vorhanden. Einen Keyword-Header zu schreiben oder gegen Regeln zu prüfen ist das eine. Sich in undokumentierten Legacy-Code zu vertiefen, um sinnvolle Tests zu schreiben, ist etwas anderes.

Seine Einschätzung war deutlich: Um dieses Niveau zu erreichen, müsste man viel in Training oder Anpassung der Modelle investieren, und bis dahin erledigt ein kleines Team die Arbeit selbst.

Selbstheilender Testcode: Wie LLMs helfen und wo das Risiko liegt

Bei der Testautomatisierung reicht die Unterstützung durch LLMs je nach Ebene von solide bis ungeklärt. Automatisierung ist Programmieren, deshalb funktioniert Hilfe im Stil von Copilot hier genauso gut wie in der normalen Entwicklung.

Auf Systemebene, über die grafische Oberfläche, kann KI helfen, Objekte wiederzuerkennen, die sich verschieben oder leicht umbenannt werden. Word Embeddings aus LLMs wurden genutzt, um alternative Locators zu finden, wenn der erste nicht mehr greift. Das geht in Richtung selbstheilender Testfälle.

Selbstheilung birgt ein echtes Risiko. Reparieren Embeddings kaputte Locators stillschweigend, können sie echte Fehlerzustände verdecken, und es wird schwer, eine versehentliche Änderung von einem echten Fehler zu unterscheiden, der Aufmerksamkeit verdient. Ein Vortrag zu dieser Idee auf der RoboCon 2025 wurde im Jahr darauf nicht mehr weiterverfolgt. Die Richtung ist offen, nicht bewiesen.

Kapazität frei machen für die Qualitätsmerkmale, die zuerst wegfallen

Der größte Wunsch an KI im Testen ist Tempo bei der Routinearbeit, damit Tester ihre Aufmerksamkeit dorthin lenken können, wo die Qualität sonst bröckelt. Unter Zeitdruck kommen funktionale Tests zuerst. Performance und Security folgen. Usability fällt als erstes Qualitätsmerkmal weg, wenn die Zeit knapp wird.

Wenn KI die funktionale Routine schnell genug abarbeitet, können Teams die Qualitäten schützen, die sonst vernachlässigt werden. Auch das Testreporting passt gut, denn Informationen in Text zusammenzufassen ist genau das, was ein Sprachmodell gut kann, und viele Tester geben diese Arbeit gern ab.

KI nutzen und KI testen wachsen wieder zusammen

Die Lücke zwischen KI zum Testen einsetzen und KI selbst testen schließt sich, je autonomer die Systeme werden. Lange sahen das wie zwei getrennte Themen aus, weil zwischen dem Modell und dem nächsten Schritt immer ein Mensch saß.

Autonomie verändert die Rechnung. Im November 2024 erschien MCP, das Model Context Protocol, und seitdem laufen immer mehr Agenten eigenständig. Je mehr Autonomie ein Agent bekommt, desto besser muss sein Ergebnis sein, weil kein Mensch mehr dazwischen sitzt, 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)

Damit wird Autonomie zu einer Testfrage. Wie viel Freiheit du einem System gibst, ist eine risikobasierte Entscheidung, nach derselben Logik, die das Testen schon immer bestimmt hat. Ein autonomer Agent, der Termine bucht oder Geld überweist, braucht Zugriff auf deine Bank- und Gesundheitsdaten, und schon dieser Zugriff ist Grund genug, ihn gründlich zu testen. Je mehr Agentenfarmen und orchestrierte Agententeams entstehen, desto mehr kommt es auf die Qualität der einzelnen Agenten an.

Häufig gestellte Fragen

Sollte ein Team ein allgemeines Modell für das Testen feinabstimmen oder kleine KI-Funktionen entwickeln?

Kleine, eng definierte Funktionen sind die sicherere Wahl. Das Team von Klaudia Dussa-Zieger hat bewusst auf ein feinabgestimmtes allgemeines LLM für das Testen verzichtet und stattdessen Helfer für einzelne Aufgaben entwickelt. Bei einem klar definierten Problem kannst du ein passendes Modell auswählen, den richtigen Kontext bereitstellen und das Ergebnis beurteilen. Projekte, die mit dem Gedanken „Wir müssen KI einsetzen“ starten, führen oft zu vagen Pilotprojekten, die nie richtig in Gang kommen.

Kann ein Sprachmodell aus Anforderungen eine fertige Testspezifikation erstellen?

Nein. Ein Prototyp, der mit „Retrieval-Augmented Generation“ erstellt wurde (zunächst auf Llama 3.1 und später auf Claude 3.5), durchlief einen vollständigen Zyklus ohne menschliches Eingreifen und funktionierte zwar, aber nicht gut. Das realistische Ziel ist ein Entwurf. Der Tester beginnt mit einer ausgefüllten Seite statt mit einem leeren Dokument und fügt die Projekterfahrung hinzu, auf die das Modell keinen Zugriff hat.

Spielt die Art des Modells eine Rolle, wenn Testcode anhand interner Regeln überprüft wird?

Ja, und zwar entscheidend. Die automatisierte Überprüfung der Implementierung von Keywords anhand der Teamregeln und eines Glossars zulässiger Begriffe lieferte mit dem Standard-Chat-Modell GPT-4o unbrauchbare Ergebnisse und wurde erst mit dem Schlussfolgerungsmodell O1 brauchbar. Die funktionierende Version kennzeichnet die offensichtlichsten Probleme innerhalb von ein oder zwei Sekunden, und Tester führen in der Regel zwei oder drei Testzyklen durch, bevor ein Entwickler die Logik überprüft.

Wie viel vom Testen der Barrierefreiheit lässt sich realistisch mit KI automatisieren?

Lange Zeit ging man davon aus, dass die Automatisierung bei der Barrierefreiheit bei etwa 40 Prozent ihre Obergrenze erreicht, da ein Mensch beurteilen muss, ob ein Text akzeptabel ist. Ein Agent, der Alternativtext für Bilder generiert, hat diese Grenze überschritten, wenn auch nicht perfekt: Manche Vorschläge duplizieren lediglich Informationen und werden von einem Spezialisten abgelehnt. Der Vorteil liegt in der Geschwindigkeit, während die fachkundige Prüferin oder der fachkundige Prüfer weiterhin entscheidet.

Können Sprachmodelle aussagekräftige Unit-Tests für undokumentierten, eingebetteten Legacy-Code schreiben?

Nein, und das ist eine klare Grenze. Das Hinzufügen von Unit-Tests zu bestehendem C-Code aus regulatorischen Gründen gleicht der Archäologie: keine Anforderungen, schlechte Dokumentation, Bedeutung muss allein aus dem Quellcode rekonstruiert werden. Solche Teams wollen keine Line-Coverage-Tests, sie wollen Testfälle, die Sinn ergeben, und genau dieses Verständnis fehlt. Um diese Lücke zu schließen, wären erhebliche Investitionen in das Training oder die Anpassung von Modellen erforderlich.

Was ist das Risiko einer selbstheilenden Testautomatisierung?

Das automatische Reparieren defekter Locator kann echte Fehlerzustände verbergen. Wort-Embeddings können einen alternativen Locator finden, wenn der erste fehlgeschlagen ist, aber das System kann eine versehentliche Änderung nicht von einer absichtlichen unterscheiden, sodass ein echter Fehlerzustand unbemerkt bleibt. Eine auf der RoboCon 2025 vorgestellte Idee wurde danach nicht weiterverfolgt. Die Richtung ist offen, nicht bewiesen.

Warum erhöht die Autonomie von Agenten die Anforderungen an das Testen von KI-Systemen?

Da zwischen den einzelnen Schritten kein Mensch eingreift, gibt es nichts, was ein schwaches Ergebnis auffängt, bevor es in die nächste Verarbeitungsstufe gelangt. Daher steigt die erforderliche Qualität stark an. Seit der Einführung des Model Context Protocol (MCP) im November 2024 laufen immer mehr Agenten eigenständig. Wie viel Freiheit man ihnen gewährt, ist eine risikobasierte Entscheidung: Ein Agent, der Termine bucht oder Geld überweist, benötigt Bank- und Gesundheitsdaten.