Generative KI im Softwaretesting bezeichnet den gezielten Einsatz von Sprachmodellen, um Testfälle zu prüfen, Edge Cases aufzudecken, Boilerplate-Code zu generieren und Code-Reviews im Dialog durchzuführen. Den größten Nutzen bringt sie, wenn Anforderungen präzise eingespeist werden. Blind generierte Unit-Tests mit hoher Code-Coverage können Fehler in der Logik verbergen statt aufdecken.
Das Wichtigste in Kürze
- KI-generierte Unit-Tests, die auf bestehendem Code basieren, decken Bugs nicht auf, sie zementieren sie, weil das Modell den fehlerhaften Code als Wahrheit behandelt.
- Generative KI für Testautomatisierung wirkt am stärksten als Einstiegshilfe: Sie senkt die Hemmschwelle für Tester ohne tiefe Coding-Erfahrung, indem sie Boilerplate-Code und Glue-Code übernimmt.
- Code-Completion-Tools wie Codium kennen den Repository-Kontext und schlagen Code vor, der auf den eigenen Page Objects und Helperklassen basiert, nicht auf fremden Trainingsdaten.
- Dokumentation, die nur für eine KI-Abfrage generiert wird und von keinem Menschen gelesen wird, produziert eine wachsende Schicht ungeprüften Datenmülls ohne Mehrwert.
- Der größte erhoffte Beitrag von GenAI für die Softwareentwicklung liegt nicht in Geschwindigkeitsgewinnen, sondern im nachhaltigen Abbau technischer Schulden durch bessere Code-Entscheidungen.
Generative KI ist im Testing angekommen und wird nicht mehr verschwinden
Generative KI hat sich im Software-Testing etabliert und wird die kommenden Jahre prägen. Wer als Firma darauf verzichtet, wird langsamer als die Konkurrenz. Diese Einschätzung teilt Matthias Zax, Testautomatisierer bei der Raiffeisenbank International und Engineering Coach für mehrere Teams.
Die Bandbreite reicht vom Test Case Design über die Generierung von Feature Files im BDD-Stil bis zur Unterstützung beim eigentlichen Code. Die Technik hat kaum noch feste Limitierungen. Sie hat aber Limitierungen, die du kennen musst, bevor du sie produktiv nutzt.
Wichtig ist die Trennung zwischen sinnvollem Einsatz und blindem Vertrauen. Ein Sprachmodell liefert Output, aber die Validierung bleibt beim Menschen. “Wenn ich nach Risiken frage, kommen Risiken. Das heißt aber nicht, dass es Risiken sind”, bringt Matthias diesen Punkt auf den Punkt.
Wie KI traditionellen Testern beim Einstieg in die Automatisierung hilft
Der größte Hebel liegt dort, wo Testern die Coding-Skills fehlen. Viele kommen aus dem manuellen oder explorativen Testen und sollen plötzlich automatisieren. Da Testautomatisierung Software-Entwicklung ist, ist dieser Sprung für sie schwierig.
Die technische Landschaft macht den Einstieg nicht leichter. CI/CD-Pipelines, Versionskontrolle mit Git, Zusammenarbeit über Pull Requests: Der Overhead ist groß, bevor überhaupt ein einziger Testfall läuft.
Hier setzt die KI als Unterstützung an. Sie hilft beim sogenannten Glue Code und beim Boilerplate Code, also bei dem Gerüst, das ein lokal lauffähiges Skript zum Leben erweckt. Matthias beschreibt das Modell als einen ständig verfügbaren Sparringspartner, den du nicht anrufen musst und der dir trotzdem direkt Feedback gibt.
Testfälle prüfen, bevor du sie automatisierst
Ein gut spezifizierter Testfall lässt sich vor der Automatisierung von einem Sprachmodell prüfen. Die Leitfrage: Ist dieser Testfall überhaupt automatisierungsfähig, fehlen Testdaten, fehlen Environments?
Die KI eignet sich auch als Konsistenzprüfung für die Testdaten selbst. In der Praxis werden oft nur die Good Cases beschrieben, die Variante, in der die Sonne scheint und die Vögel singen. Edge Cases und Negativtests fehlen häufig.
Hier liegt ein realer Nutzen, wenn du konkret fragst. Eine User Story einfach hineinkopieren und um Feedback bitten bringt nur generische Antworten. Frag stattdessen gezielt: Sind alle Edge Cases abgedeckt? Lassen sich die Testdaten verbessern? Welche Akzeptanzkriterien sind noch offen? Bei einem ganzen Feature mit mehreren Akzeptanzkriterien zahlt sich diese Genauigkeit aus.
Vertrauliche Daten gehören nicht in ein offenes Sprachmodell
Userdaten in eine öffentliche KI zu kopieren ist im Finanzsektor keine Option. Wer in einem regulierten Umfeld arbeitet, braucht eine Lösung, bei der die Prompts das Unternehmen nicht verlassen.
Bei der Raiffeisenbank International ist das Sprachmodell internalisiert. Das Modell ist eingekauft, aber sämtliche Prompts bleiben in der Firma. Dadurch lassen sich auch reale Daten zumindest ansatzweise verwenden, ohne dass sie nach außen gelangen.
Für die Code-Arbeit gibt es Code-Completion-Tools, die sich intern hosten lassen. Dann ist die Vertraulichkeit ohnehin keine Frage mehr, sondern nur noch ein Kostenfaktor. Matthias rechnet damit, dass sich der Return on Investment einstellt.
Generierter Code, der kompiliert, ist noch nicht korrekt
Compilierbarer Code ist kein Beweis für funktionierenden Code. Er kann laufen und trotzdem nicht das tun, was du beabsichtigt hast. Wer nicht sicher programmieren kann, übersieht diese Lücke leicht und hält ein erfolgreiches Kompilat schon für ein fertiges Ergebnis.
Die Qualität der Modelle hat sich deutlich verbessert. Die frühen Copilots waren schlecht. Matthias vermutet sogar, dass er mit den alten Versionen langsamer war als ganz ohne, weil er ständig falsche Code-Suggestions wegescapen oder refaktorieren musste.
Heute schlagen die Tools auch Lösungen vor, die der erfahrene Entwickler selbst nicht kannte. Damit wird die KI nebenbei zum Lerntool, weil sie zum Code immer eine Erklärung mitliefert. Eine neue Library, ein unbekannter Ansatz: Du liest die Begründung und nimmst etwas mit.
In der Praxis bleibt Refactoring meist nötig. Der generierte Code ist ein Startpunkt, kein Endprodukt.
Warum Unit-Tests automatisch zu generieren der falsche Weg ist
Funktionen in ein Sprachmodell zu kippen und sich 100 Prozent Code Coverage generieren zu lassen, gehört zu den schlechtesten Anwendungen überhaupt. Das Modell erreicht die Abdeckung. Aber wenn ein Bug in der Software steckt, deckt der generierte Test genau diesen Bug mit ab, statt ihn zu finden.
Der Grund liegt in der Richtung. Ein aus dem bestehenden Code abgeleiteter Test validiert nicht, ob der Code richtig ist. Er zementiert nur das, was schon da ist, fehlerhaft oder nicht.
Tests aus der User Story zu generieren ist etwas besser, aber auch hier wandert ein Fehler in der Story direkt in die Tests. Matthias bevorzugt den umgekehrten Weg: die Tests selbst schreiben und sich den Business Code generieren lassen.
Daraus entsteht eine Zukunftsvision, die das Prinzip von Test Driven Development weiterdenkt:
Meine Idee wäre, dass ich meine Tests in Playwright schreibe und sich die Applikation hinter den Kulissen baut. Ich kann meine Applikation nur über die Tests ändern.
Das würde das Testen auf ein neues Niveau heben, weil deutlich mehr getestet würde als heute und die Applikation zu einem hohen Anteil generiert wäre. Look and Feel, Responsiveness und das konkrete Verhalten einer Anwendung machen das schwer vorstellbar. Unmöglich ist es nicht.
Code Completion kennt heute deinen Kontext
Moderne Code-Completion-Tools schlagen Code auf Basis deines eigenen Repositories vor, nicht auf Basis fremder Daten aus dem Netz. Die KI kennt deine Page Objects, deine Keywords, deine Helper-Klassen.
Das ändert die Arbeitsweise spürbar. Die Vorschläge stammen aus deinem Projekt, also musst du Funktionen nicht umschreiben. Matthias nutzt dafür weniger ein Chat-Interface und mehr die Completion-Tools direkt in der IDE, privat zum Beispiel Codium für Open-Source-Arbeit. Er beschreibt das als die nächste Stufe der Code Completion, die man bisher von Werkzeugen wie IntelliJ kannte.
Ein Anti-Pattern wandert damit aus den Repositories: das exzessive Kommentieren. Bei den älteren Copilots war es nötig, lange Kommentare zu schreiben, damit der passende Code folgte. Die guten Coding-Praktiken von früher gelten weiter. Code sollte so geschrieben sein, dass er wenige Kommentare braucht, und nur die Stellen kommentieren, die es wirklich erfordern. Sonst wird er unlesbar.
Generierte Dokumentation, die niemand liest, ist ein Anti-Pattern
Dokumentation zu generieren, die niemand liest, löst kein Problem, sondern produziert ein neues. Das Muster: Jemand kopiert zehn User Stories in ein Modell und lässt sich daraus eine fünfzehnseitige Teststrategie schreiben, halluzinierte Lücken inklusive.
Das Ergebnis ist eine Suppe aus generiertem Text, die niemand liest, die aber jetzt durchsuchbar ist. Wenn Unternehmen anschließend ihre Wikis und Repositories in den Kontext eines Sprachmodells bringen, um darüber zu suchen, durchsucht die KI am Ende ihre eigene, ungelesene Ausgabe. Ein in sich geschlossenes System ohne Substanz.
Es gibt sinnvolle Varianten. Readme-Files lassen sich gut generieren, weil die KI aus dem Git-Repository ableiten kann, was hineingehört. Den Entwurf refaktorierst du danach. Das nutzt Matthias selbst.
Auch in regulierten Branchen rechtfertigt das kein 200-Seiten-Testhandbuch. Der Regulator schreibt nicht 200 Seiten vor, sondern verlangt, dass du dokumentierst, wie du testest. Überschaubare Templates mit den wichtigsten Informationen reichen. Architektur als Bild, klar markiert, was getestet wird und was nicht, was extern liegt. Was niemand liest, hilft niemandem.
Technische Schuld besser in den Griff bekommen
Das größte Versprechen der KI für Matthias liegt im Umgang mit technischer Schuld. Applikationen sollen langlebig sein, lassen sich aber oft nicht mehr weiterentwickeln, weil niemand mehr weiß, wie sie gebaut wurden und Upgrades unmöglich werden.
Legacy entsteht häufig an einem konkreten Punkt. Etwas wird zu Legacy, sobald die Entwickler, die es programmiert haben, die Firma verlassen. Dann kann es niemand mehr.
Statische Codeanalyse hat in den vergangenen Jahren geholfen, Probleme sichtbar zu machen. Die Reaktion darauf, eigene Refactoring-Sprints anzusetzen, ist besser als nichts, aber kein guter Zustand. Die technische Schuld wächst trotzdem weiter.
Die Hoffnung ist, dass KI die Ingenieursarbeit besser macht, statt sie nur zu beschleunigen. Die falsche Richtung wäre, Teams zu verkleinern, weil sie mit KI-Tools schneller seien. Die produktive Richtung: weniger Klon-Code, keine Klassen mit 2000 Zeilen, dokumentierte Entscheidungen dort, wo sie zählen, hinterfragte Architektur und für moderne Anwendungen eine moderne Struktur, ob Microservices oder ein sauber modularer Monolith.
Reguläre Ausdrücke verstehen, ohne sie auswendig zu können
Ein konkreter Alltagsnutzen verdient eine eigene Erwähnung: reguläre Ausdrücke. Du gibst eine RegEx ein und fragst, was sie bedeutet, oder du lässt sie dir aus einer Beschreibung generieren.
Genau diese kleinen Dinge senken die tägliche Reibung. Du musst dir über Syntax keine Gedanken mehr machen, die du selten brauchst und nie ganz behältst. Etwas in menschliche Sprache zu übersetzen und aus menschlicher Sprache zu erzeugen, ist der Teil, der den Arbeitsalltag spürbar leichter macht.
