Lohnt sich Testautomatisierung in einem Projekt, das schon Jahre läuft? Mit der richtigen Kombination aus eigenem Testframework und einem KI-Agenten lautet die Antwort heute anders als noch vor zwei Jahren.
Testautomatisierung ist eine der am häufigsten genannten Maßnahmen zur Qualitätssicherung in Softwareprojekten und gleichzeitig eine der am häufigsten verschobenen. Die Gründe sind bekannt: Der Aufwand wirkt anfangs hoch, der Nutzen lässt sich schwer beziffern, und in laufenden Projekten mit gewachsener Codebasis ist der Einstieg ungleich schwerer als auf der grünen Wiese.
Die Folgen sind in Studien gut dokumentiert: Eine Untersuchung des IBM Systems Sciences Institute zeigt, dass ein Fehler, der erst in der Produktion entdeckt wird, im Schnitt rund 100-mal teurer zu beheben ist als ein Fehler, der bereits in der Designphase auffällt; und immer noch etwa fünfzehnmal teurer als ein Fehler, der während der Entwicklung gefunden wird (IBM via Functionize). Konkret beziffern Branchenanalysen die Kosten eines Fehlers in der Anforderungsphase auf rund 100 US-Dollar, in der QA-Phase auf 1.500 US-Dollar und in der Produktion auf bis zu 10.000 US-Dollar (CloudQA: How Much Do Software Bugs Cost? 2025).
Hinzu kommt: Eine Analyse für das Jahr 2024 zeigt, dass rund 85 % der Bugs in Webanwendungen erst von Nutzerinnen und Nutzern entdeckt werden — nicht in der Testphase (CloudQA 2025). Reife Engineering-Organisationen streben laut den DORA-Metriken demgegenüber eine Defect Escape Rate von unter 10 % an (Opsera: DER Guide). Die Lücke zwischen diesen beiden Zahlen markiert eines der größten Optimierungspotenziale moderner Softwareentwicklung.
Genau hier setzt unser Ansatz an: Testautomatisierung muss schnell wirksam werden, auch in Projekten, die schon lange laufen. Und sie muss bezahlbar bleiben.
Wir nutzen seit mehreren Jahren unser Testframework TOMAS, das auf C# basiert und die Erstellung von Automatisierungsskripten in einem XAML-Dialekt erlaubt. Es ist ursprünglich für die Automatisierung von Windows-Desktop-Anwendungen entstanden und inzwischen zu einem umfangreichen und modularen Toolset für die Automatisierung von Front- und Backendprozessen geworden. TOMAS lässt sich in die CI/CD-Pipeline integrieren und ist als Codebasis vollständig transparent. Kein Vendor Lock-in, kein Blackbox-Tool. Das war uns bei der Entwicklung wichtig.
Das eigentliche Problem war damit aber nicht gelöst: Auch mit einem guten Framework kostet das Schreiben jedes einzelnen Testfalls Zeit: Analyse, Implementierung und Stabilisierung. Vor allem bei langlaufenden Projekten, die ohne Testautomatisierung im Sinn erstellt wurden, entsteht ein Aufwand, den viele Auftraggeber im Tagesgeschäft kaum schultern können.
Unsere Antwort darauf: Ein selbst entwickelter KI-Agent, der die Testfälle automatisch generiert. Angebunden über spezialisierte Skills, integriert in die Entwicklungsumgebung, mit direktem Zugriff auf die zu testende Anwendung und das bestehende TOMAS-Framework.
Der Agent ist nicht einfach ein vorgeschaltetes Sprachmodell, das ein paar Code-Snippets zusammenwürfelt. Wir haben ihn gezielt dafür entwickelt, in unserer konkreten Umgebung produktiv zu sein. Das bedeutet:
Das Ergebnis ist kein fertiger, freigegebener Testfall. Das ist uns wichtig und sollte jedem klar sein, der über KI-gestützte Testautomatisierung nachdenkt: Was der Agent liefert, ist ein qualifizierter Entwurf. Erst die Prüfung durch erfahrene Software- und QA-Engineers macht daraus einen Test, dem man vertrauen kann.
Die Versuchung ist groß, KI-generierten Code unbesehen zu übernehmen. Unsere Erfahrung zeigt: Genau das ist der schnellste Weg zu einem instabilen Testbestand. Tests, denen niemand vertraut, sind schlimmer als kein Test, weil sie Kapazität binden, ohne Sicherheit zu geben.
Deshalb haben wir den Workflow bewusst zweistufig angelegt:
Diese Aufteilung hat sich bewährt. Die Zeitersparnis liegt nicht im wegfallenden Review, sondern im wegfallenden Erstaufwand. Wo früher ein Tag für die Analyse und das initiale Schreiben des Tests fällig war, prüft heute eine Entwicklerin oder ein Entwickler in zwei Stunden den Vorschlag, korrigiert Schwachstellen und gibt frei. In Summe ein deutlich kleinerer Aufwand bei gleichbleibender Qualität.
Klassisch gilt: Testautomatisierung ist umso teurer, je später man damit anfängt. In gewachsenen Codebasen fehlen oft saubere Strukturen, die Oberflächen sind komplex, und die Dokumentation hinkt der Implementierung hinterher.
Genau dort spielt der Agent seine Stärke aus. Er analysiert die Anwendung in ihrem aktuellen Zustand, nicht in dem Zustand, den eine veraltete Spezifikation beschreibt. Er erkennt, welche Elemente in der UI existieren, wie sie sich verhalten und wie ein Testpfad realistisch aussieht. Das macht Testautomatisierung in Bestandsprojekten erstmals zu einer Investition mit überschaubarem Risiko — und nicht zu einem mehrjährigen Modernisierungsprojekt.
Wir sehen den Effekt in den Zahlen: In einem unserer Projekte ist die Quote der Bugs, die erst nach der Auslieferung gefunden werden, über drei Hauptversionen hinweg von rund 25 % auf unter 9 % gesunken. Ein Teil davon geht auf strukturelle Verbesserungen zurück. Ein wachsender Teil aber auf die zunehmende Testabdeckung und auf die Geschwindigkeit, mit der wir neue Tests in den Bestand aufnehmen können.
Aus der Arbeit mit dem Agenten haben sich einige Erkenntnisse herauskristallisiert, die für jedes vergleichbare Vorhaben relevant sind:
Stabilität schlägt Umfang. Fünfzehn stabile Tests sind wertvoller als fünfzig instabile. Der Agent kann viel produzieren, die Kunst ist, das richtige Maß zu finden.
Priorisierung gewinnt man durch Daten. Welche Programmbestandteile sollen zuerst automatisiert werden? Nicht die, die am komplexesten sind, sondern die, die am häufigsten genutzt werden oder deren Ausfall die größte Auswirkung hat. Telemetrie liefert hier die belastbarsten Antworten.
Pipeline-Integration ist kein Bonus, sondern Voraussetzung. Tests, die auf einer einzelnen Entwicklermaschine laufen, sind kein Sicherheitsnetz. Sie werden zum Sicherheitsnetz, wenn sie bei jedem Build automatisch laufen und Ergebnisse sichtbar machen.
Der Agent ist ein Assistent, kein Ersatz. Erfahrene Test- und Entwicklungsteams werden durch KI produktiver, nicht überflüssig. Wer das umgekehrt sieht, riskiert Qualität und Vertrauen gleichermaßen.
So überzeugend die Ergebnisse sind — ehrlich gehört dazu: Es gibt Themen, die wir kontinuierlich verbessern.
Der Agent ist nur so gut wie die Informationen, die er bekommt. Komplexe fachliche Validierungen — etwa branchenspezifische Regeln, die nicht aus der UI ablesbar sind — braucht es weiterhin als Vorgabe. Wir arbeiten daran, fachlichen Kontext systematisch in die Schnittstelle einzubinden, ohne dass der Agent dabei zu einem Datensammler wird.
Und zweitens: Geschwindigkeit ist kein Selbstzweck. Wir messen nicht, wie viele Tests der Agent pro Stunde produziert, sondern wie viele Bugs durch automatisierte Regression früher gefunden werden. Das ist die einzige Kennzahl, die zählt.
Der Einsatz von KI in der Testautomatisierung verändert nicht die Grundprinzipien guter Qualitätssicherung. Was sich verändert, ist der Aufwand, mit dem diese Prinzipien umgesetzt werden können. Wo Testautomatisierung in Bestandsprojekten lange als „zu teuer, zu spät" galt, wird sie heute zu einer messbar wirtschaftlichen Option.
Für uns ist die Kombination aus dem TOMAS-Framework und unserem KI-Agenten ein praktischer Schritt nach vorn: Keine Hype-Technologie, sondern ein konkretes Werkzeug, das die Arbeit unserer Teams produktiver macht und unseren Kunden hilft, Qualität früher zu erreichen. Bugs, die wir im Sprint finden, sind ein Vielfaches günstiger als Bugs, die in der Produktion auffallen. Diese Rechnung hat sich nicht geändert. Verändert hat sich nur, wie schnell und wie zugänglich wir den Sprint absichern können.
Sie überlegen, wie Testautomatisierung in Ihrem Projekt einen messbaren Beitrag leisten kann — auch wenn die Codebasis schon länger lebt? Sprechen Sie uns gerne an.