KI in der Testautomatisierung: Ein Kundenprojekt zeigt, was möglich ist
Fünf Herausforderungen, die wir erst durch KI sichtbar gemacht haben
Wie viele Stunden gehen in deinem Testautomatisierungsprojekt in Wartung statt in neue Abdeckung? Und wie viel von dem Wissen, das dein Projekt zusammenhält, steckt nur in den Köpfen von zwei oder drei Personen?
Wir haben uns diese Fragen in einem Kundenprojekt im Versicherungsumfeld gestellt: mehrere Hundert automatisierte Geschäftsvorfälle über mehrere Mandanten, geprüft von der Oberfläche bis in die Datenbank, in einem regulierten Umfeld, in dem jeder Testlauf über eine Release-Freigabe mitentscheidet. Als wir Claude Code eingeführt haben, kamen fünf Probleme ans Licht, die uns schon lange ausgebremst hatten, nur hatte sie bisher niemand offen angesprochen.
Ausgangslage
Wir verantworten die End-to-End-Testautomatisierung dieser Bestandsführungsplattform: Testsuiten, die über die gesamte Kette von der Oberfläche über die Geschäftslogik und die Schnittstellen bis in die Datenbank prüfen. Die Ergebnisse müssen revisionssicher dokumentiert sein.
Ein solches Projekt wächst. Und mit ihm wachsen Dinge, über die selten jemand spricht, weil sie sich schleichend einstellen. Genau diese Themen waren es, die uns tatsächlich Zeit gekostet haben. Nicht das Schreiben neuer Tests.
Die erste Erkenntnis war deshalb unbequem: Ein KI-Assistent macht ein Projekt nicht automatisch schneller. Er verstärkt, was da ist. Vorhandene Ordnung und vorhandenes Chaos gleichermassen.
Pain Point 1: Zu starke Abhängigkeit von einzelnen Personen
Das Problem: In jedem gewachsenen Testprojekt gibt es Regeln, die nirgends stehen. Warum bestimmte Testsuiten nicht parallel laufen dürfen. Warum ein automatischer Wiederholungsversuch an einer bestimmten Stelle mehr schadet als nützt. Warum eine Fehlermeldung aus dem Testmanagement fast nie das bedeutet, was sie sagt. Dieses Wissen lag bei uns bei zwei, drei Personen.
Die Folgen kennt jedes Team. Die Einarbeitung neuer Kolleginnen und Kollegen dauert lange. Fehler wiederholen sich, weil niemand sie dokumentiert hat. Und das Projekt hängt an Verfügbarkeit einzelner Personen, was in einem Beratungsumfeld ein echtes Risiko ist.
Wie wir es gelöst haben: Wir mussten dem Assistenten erklären, wie das Projekt funktioniert. Und um es ihm zu erklären, mussten wir es zuerst selbst klar ausformulieren. Aus dieser Notwendigkeit ist ein Regelwerk entstanden, das im Repository liegt, versioniert und für alle sichtbar.
Was dabei herauskam: Der grösste Gewinn war nicht der Assistent. Es war die Dokumentation, die wir seinetwegen geschrieben haben. Diese Regeln sind heute das, was neue Teammitglieder als Erstes lesen. Sie beantworten genau die Fragen, die man sonst in der dritten Woche stellt, nachdem man den Fehler bereits gemacht hat.
Pain Point 2: Grüne Tests, die nichts prüfen
Das Problem. Das ist das unangenehmste Thema in der Testautomatisierung, und es wird selten offen angesprochen. Ein kaputter Test wird rot und fällt auf. Ein schlechter Test wird grün.
Wenn eine Prüfung auf eine leere Ergebnismenge angewendet wird, läuft sie durch. Der Test bleibt in der Suite, verbraucht Laufzeit und erzeugt Vertrauen, das nicht gerechtfertigt ist. Für eine Release-Entscheidung ist das schlimmer als gar kein Test, weil niemand nachschaut.
Genau hier liegt das eigentliche Risiko von KI-Unterstützung im Testing. Ein Sprachmodell optimiert auf Plausibilität, nicht auf Korrektheit. Es liefert eine überzeugend klingende Antwort, auch wenn es die richtige nicht kennen kann. In unserem Fall betraf das interne Fachschlüssel, die sich nicht aus dem ableiten lassen, was auf der Oberfläche steht, obwohl es genau so aussieht.
Wie wir es gelöst haben: Wir haben eine Regel formuliert, die nicht Code betrifft, sondern Verhalten. Ein Wert wird entweder aus einem vergleichbaren, bereits belegten Testfall übernommen oder er wird nicht gesetzt, sondern als offener Punkt markiert und im ersten Lauf verifiziert. Ein Wert, der eine Prüfung grün laufen lässt, ohne belegt zu sein, gilt bei uns als Defekt.
Was dabei herauskam: Das Verhalten verschiebt sich von immer eine Antwort liefern hin zu sichtbar machen, wo die Antwort fehlt. Ein ehrlicher roter Test ist mehr wert als ein trügerischer grüner. Das gilt übrigens unabhängig von KI. Der Assistent hat uns nur gezwungen, es endlich aufzuschreiben.
Pain Point 3: Wartungsaufwand statt Weiterentwicklung
Das Problem: In vielen Automatisierungsprojekten kippt das Verhältnis irgendwann. Das Team verbringt mehr Zeit damit, bestehende Tests am Leben zu halten, als neue Abdeckung aufzubauen. Zwei Ursachen dominieren. Instabile Zugriffe auf Oberflächenelemente, die bei jedem Deployment brechen. Und Duplikate, weil bereits vorhandene Bausteine nicht gefunden und deshalb ein zweites Mal gebaut werden.
Aufzeichnungswerkzeuge verschärfen beides. Sie schlagen bevorzugt genau die Zugriffsarten vor, die im Moment der Aufzeichnung funktionieren und danach am schnellsten kaputtgehen.
Wie wir es gelöst haben: Wir haben eine verbindliche Rangfolge definiert, welche Zugriffsart in welcher Situation zu verwenden ist, und ausdrücklich benannt, welche verboten sind. Dazu kam eine Prüfpflicht. Bevor ein neuer Baustein entsteht, wird in vier definierten Schritten geprüft, ob es ihn bereits gibt.
Was dabei herauskam: Die Regeln wirken doppelt. Der Assistent hält sich daran, und das Team hat zum ersten Mal einen geschriebenen Massstab für Reviews. Vorher war Wartbarkeit eine Frage der Erfahrung. Jetzt ist sie überprüfbar.
Pain Point 4. Fehlersuche, die in die falsche Richtung läuft
Das Problem: Ein Testlauf schlägt fehl. Die Meldung im Reporting sagt, ein Objekt sei nicht gefunden worden. Also sucht man nach dem fehlenden Objekt. Tatsächlich war ein Zugangstoken abgelaufen und die Schnittstelle antwortet aus Sicherheitsgründen bewusst irreführend.
Dazu kam bei uns ein hausgemachtes Problem. In älterem Code wurde die technische Fehlerspur verworfen, bevor der Fehler weitergemeldet wurde. Im Reporting stand danach zwar ein Fehler, aber ohne jede Information darüber, wo er entstanden ist. Jede Analyse begann bei null.
Beides zusammen kostete regelmässig Stunden. Und ein Assistent ohne dieses Wissen sucht sehr effizient in die völlig falsche Richtung.
Wie wir es gelöst haben: Die technische Fehlerspur bleibt erhalten, das ist heute eine harte Regel. Und die bekannten irreführenden Fehlerbilder stehen im Regelwerk, jeweils zusammen mit dem konkreten Diagnoseschritt, der die wahre Ursache in einer Minute klärt.
Was dabei herauskam: Aus wiederkehrenden Stunden wurden Minuten. Der eigentliche Fortschritt ist aber, dass dieses Wissen nicht mehr verloren geht, wenn die Person im Urlaub ist, die es hatte.
Pain Point 5: Compliance und Vertraulichkeit
Das Problem: In einem regulierten Umfeld ist die Frage, was in ein Chatfenster kopiert werden darf, keine akademische. Wer einen Anmeldefehler untersucht, kopiert im Zweifel die komplette Konfiguration in ein Werkzeug, weil es gerade schnell gehen muss. Das Risiko liegt im menschlichen Verhalten. Technisch lässt sich das nicht wegkonfigurieren.
Wie wir es gelöst haben: Klare, ausgeschriebene Leitplanken. Keine Zugangsdaten und keine Konfigurationsinhalte in Prompts, Logs, Tickets oder Commit-Nachrichten. Keine Umgehung etablierter Prüfmechanismen im Versionsmanagement ohne ausdrückliche Anweisung. Keine Eingriffe in gemeinsam genutzte Grundbausteine ohne Bewertung der Auswirkung auf den gesamten Testbestand.
Was dabei herauskam: Wer KI-Unterstützung in einem regulierten Umfeld einführt, braucht diese Punkte schriftlich. Nicht als mündliche Absprache. Sie sind auch das, was in einer Prüfung als Erstes nachgefragt wird.
Die zentrale Erkenntnis
Ein KI-Assistent ist so gut wie der Kontext, den man ihm gibt. Und dieser Kontext entsteht nicht von selbst.
Der messbare Zeitgewinn stellte sich bei uns dort ein, wo eine klare Regelgrundlage vorhanden war. Neue Testfälle nach vorhandenem Muster, Übersetzung von Aufzeichnungen in wartbaren Code, wiederkehrende Strukturarbeit. Wo diese Grundlage fehlte, entstand Nacharbeit, teilweise mehr als bei manueller Erstellung. Das ist die ehrliche Bilanz, und sie ist der Grund, warum wir zuerst über Struktur und dann über Werkzeuge sprechen.
Bemerkenswert ist, dass keiner der fünf Punkte oben ein KI-Problem ist. Undokumentiertes Wissen, trügerisch grüne Tests, Wartungsschulden, irreführende Fehlerbilder und unklare Vertraulichkeitsregeln gab es vorher schon. Der Assistent hat sie nur sichtbar und dringend gemacht.
Was das für dein Projekt bedeutet
Wenn du überlegst, KI-Unterstützung in deine Testautomatisierung zu bringen, sind das aus unserer Erfahrung die richtigen Einstiegsfragen:
- Wo in deinem Projekt kann etwas schiefgehen, ohne dass es jemand merkt?
- Welches Wissen liegt bei einzelnen Personen und nirgendwo sonst?
- Wie viel deiner Kapazität geht in Wartung statt in neue Abdeckung?
- Woran erkennst du im Review, ob ein Test wirklich prüft, was sein Name behauptet?
- Was darf ein Mitarbeitender in ein KI-Werkzeug eingeben, und wo steht das geschrieben?
- Wer diese Fragen beantworten kann, hat den grösseren Teil der Arbeit bereits geleistet. Das Werkzeug ist dann der einfachere Schritt.
- Du möchtest wissen, wie sich das auf deine Situation übertragen lässt? Sprich mit uns.
In einem Folgebeitrag betrachten wir das Thema aus Compliance-Sicht. Welche Nachweise erwartet eine Prüfung, wenn KI-Unterstützung im Testprozess eingesetzt wird.
