KI-Revolution in der Testautomatisierung

Machine Learning im Software-Testing bezeichnet den Einsatz von Algorithmen, um wiederkehrende Analyseaufgaben in der Testautomatisierung zu übernehmen. Fehlgeschlagene Tests werden dabei automatisch nach Fehlerursachen gruppiert, große Testportfolios als Zustandsgraph visualisiert und risikobasiert priorisiert. So gewinnen Teams Zeit für das Schreiben neuer Tests statt für reine Wartung.

Das Wichtigste in Kürze

• Fehlgeschlagene automatisierte Tests lassen sich per Machine Learning auf wenige gemeinsame Ursachen verdichten, sodass Tester täglich nicht mehr hunderte Einzelfälle, sondern nur noch sieben bis acht Fehlerklassen analysieren müssen.
• Aus bestehenden Logfiles und Testausführungsdaten entsteht automatisch ein Graph-Modell der Applikation, der Redundanzen, Fehler-Hotspots und nicht integriert getestete Bereiche auf einen Blick sichtbar macht.
• Die Auswahl relevanter Tests für eine begrenzte Zeitbox funktioniert über gewichtete Risikofaktoren wie Kritikalität, Codeänderungen, Traceability zu Bugs und Zeitpunkt der letzten Ausführung.
• Visuelles Regressionstest per KI erkennt unerwartete Zustandsänderungen in der Oberfläche rein anhand von Screenshots, ohne dass dafür explizite Validierungen im Testfall definiert sein müssen.
• Der Ansatz, einen menschlichen Qualitätswächter im sicherheitskritischen Bereich zu behalten, begründet sich damit, dass Maschinen nur den Kontext verstehen, den man ihnen explizit übergibt.

Warum jeder zweite Testautomatisierer im Wartungssumpf steckt

Wer konsequent automatisiert, läuft irgendwann gegen eine Skalierungsgrenze. Die Tests sind da, das Framework steht, alles folgt den Regeln der Kunst, und trotzdem beginnt jeder Arbeitstag mit einem Stapel fehlgeschlagener Testfälle, die durchgesehen werden wollen.

Das Muster ist immer dasselbe. Ein Entwickler ändert ein Merkmal an einem UI-Element, am nächsten Morgen stehen 50 rote Tests im Report, und der Automatisierer verbringt seine Zeit mit Nachbessern statt mit neuen Tests.

Irgendwann kippt das Verhältnis komplett: Die Wartung frisst die gesamte Kapazität auf. Neue Tests entstehen nicht mehr, das Portfolio wird nur noch am Leben und grün gehalten. Genau an diesem Punkt wird Testautomatisierung zur Last statt zum Hebel.

Der grösste Einzelposten in diesem Wartungsaufwand ist das Durcharbeiten geänderter und fehlgeschlagener Tests. Hier setzen die meisten Machine-Learning-Ansätze für das Testen an, weil hier der Schmerz am konkretesten ist.

Wie Machine Learning fehlgeschlagene Tests auf wenige Ursachen reduziert

Der Kerngedanke: Statt 200 einzelner roter Tests durchzusehen, bekommst du sieben oder acht Fehlerursachen serviert. Du arbeitest die Ursachen ab, nicht jeden einzelnen Testfall.

Die Grundlage dafür sind Logfiles, die ohnehin schon existieren. Der Ansatz baut bewusst auf vorhandenen Daten auf, statt zehntausende neue Datensätze zu generieren oder mühsam zu labeln. Es ist im Kern Big Data auf Testergebnissen.

Aus welchem Tool die Logfiles kommen, ist für den Algorithmus zweitrangig. Ein einfacher Adapter überführt kommerzielle Tools wie auch Open-Source-Frameworks in ein gemeinsames Format. Entscheidend ist nur, dass sich auslesen lässt, wo ein Test startet, wo ein Testschritt anfängt und aufhört, wo der Fehler steckt und welche Fehlermeldung samt Stacktrace dranhängt.

Aus diesen technischen Informationen klassifiziert die Maschine die Ursache: ein Datenbankproblem, ein UI-Problem, ein Problem mit dem Test-Automation-Framework, ein Netzwerkproblem. Weil Logfiles technische und nicht natürliche Sprache sind, reichen oft einfache Verfahren. Meistens genügt ein Random Forest, nur gelegentlich braucht es ein neuronales Netz.

So startet die Klassifikation ohne grossen Vorlauf

Du beginnst manuell und in kleinem Rahmen. Bei jedem Fehlschlag trägst du ein, worum es sich handelt. Das ist ohnehin gute Praxis zur Schwachstellenanalyse und kostet kaum Zusatzaufwand.

Grössere Mengen lassen sich über reguläre Ausdrücke abdecken. Steht im Logfile “database error”, klassifiziert eine Regular Expression alle entsprechenden Fälle automatisch als Datenproblem. Ob das inhaltlich in jedem Einzelfall stimmt, sei dahingestellt, aber es erzeugt schnell genug Trainingsdaten.

Auf diesen Klassifikationen trainiert der Algorithmus und geht in den Probebetrieb. Beim nächsten Lauf schlägt er für bekannte Muster eine Ursache vor, etwa mit einer Zuverlässigkeit von 95 Prozent. Bei unsicheren Fällen hält er sich zurück und überlässt die Einschätzung dem Menschen, der bestätigt oder widerlegt.

Cluster geben auch dem Rest eine Struktur

Für die Fehlschläge, die sich noch nicht einsortieren lassen, hilft unsupervised learning. Statt eine Ursache zu erraten, gruppiert das Verfahren ähnliche Fälle rein anhand ihrer technischen Informationen.

Was diese Cluster verbindet, ist zunächst unbekannt. Aber die Fälle sind sich ähnlich, und dem fertigen Cluster muss man nur noch einen Namen geben, um auch diese Fehlschläge zu klassifizieren. So lässt sich das Konzept eigenständig weitertreiben.

Ein Nebeneffekt entpuppte sich als ähnlich wertvoll wie die Klassifikation selbst. Weil alle Logfiles, auch die der getesteten Systeme, in einer zentralen Plattform liegen, entsteht ein Gesamtüberblick darüber, was während eines Testlaufs passiert ist. Diese Metadaten machen die Analyse der wenigen verbliebenen Fehlschläge erheblich einfacher.

Test-based Modeling: Aus Testdaten entsteht ein Modell der Applikation

Grosse Testportfolios werden verständlich, wenn man sie als Graph darstellt. Bei 10.000 automatisierten Tests beantwortet keine Coverage-Kennzahl die Frage, was diese Tests eigentlich tun.

Der Trick liegt in der Struktur, die Testautomatisierung ohnehin hat. Ob Behavior-Driven Development mit Cucumber, keyword-basierte Ansätze oder andere klassische Strukturen: Jeder Testfall ist eine Abfolge fachlicher Testschritte.

Aus dieser Abfolge wird ein Graph. Jeder Zustand der Applikation ist ein Knoten, jeder Testschritt eine Kante. Jeder durchgeführte Testfall ergibt einen Pfad, und übereinandergelegt entsteht ein Graph fachlicher Aktionen. Diese Pfade lassen sich direkt aus den Logfiles oder dem Testtool ziehen.

Das Ergebnis ist die Umkehrung des klassischen Vorgehens. Statt Model-based Testing aus einem vorab gebauten Modell entsteht hier Test-based Modeling: Aus den realen Tests entsteht implizit ein Modell der Applikation.

Das menschliche Auge erkennt in diesem Graphen schnell Muster. Häufig besuchte Knoten werden grösser dargestellt, fehlgeschlagene Schritte rot eingefärbt. So werden Konzentrationen, Redundanzen und Fehler-Hotspots sichtbar. Auch wenn der Graph in zwei Komponenten zerfällt, fällt das auf, ein Hinweis auf Bereiche, die nie integriert miteinander getestet wurden.

Wie aus dem Modell neue Tests und Testdaten entstehen

Das Modell lässt sich nicht nur ansehen, sondern abfragen. Du kannst fragen, ob es einen Testfall gibt, der zwei bestimmte Knoten verbindet, und aus dem Graphen wieder neue Tests ableiten.

Weil die einzelnen Testschritte bereits automatisiert sind, lässt sich aus einer Knotenfolge zumindest Boilerplate-Code für einen neuen Test generieren. Validierungen und Testdaten müssen noch ergänzt werden, aber das Gerüst steht.

Für die Testdaten kommen Large Language Models ins Spiel. Ein Modell wie ein GPT liefert plausible Werte: einen passenden Username oder ein ungültiges Login, das auch ein echter Nutzer treffen würde.

Der Grund, warum das funktioniert: Diese Modelle haben ihre Annahmen aus natürlichsprachlichem Text gelernt. Sie treffen Annahmen, die Menschen wahrscheinlich auch treffen würden. Damit verlässt der Ansatz das rein spezifikationsbasierte Testen und nähert sich einem teilautomatisierten, explorativen Test.

Nicht jedes Problem braucht Machine Learning

Das Ziel war, Probleme zu lösen, nicht Machine Learning einzusetzen. Diese Unterscheidung prägt mehrere der nützlichsten Bausteine.

Die Visualisierung grosser Testportfolios kommt ohne Machine Learning aus und funktioniert trotzdem überraschend gut. Auch die risikobasierte Auswahl von Tests ist im Kern eine Optimierungsaufgabe, kein Lernproblem.

Daneben stehen Bausteine wie Self-Healing von UI-Erkennungsmerkmalen. Eigentlich gehören saubere UI-Merkmale schon in den Entwicklungsprozess, ihr Fehlen ist ein qualitätsminderndes Merkmal. Bei Standardprodukten oder dort, wo sich das nicht beeinflussen lässt, ist Self-Healing aber durchaus hilfreich.

Wie risikobasierte Testauswahl in einer Zeitbox funktioniert

Statt eines fest handverlesenen Smoke-Test-Sets wählt der Ansatz die richtigen Tests dynamisch aus. Die Frage lautet nicht mehr “welche Tests stehen im Smoke-Set”, sondern “du hast 15 Minuten, hol die wertvollsten Tests heraus”.

Die Grundlage ist Traceability. Ein Test ist mit einer User Story verlinkt, die User Story mit einem Bug, der Bug ist behoben worden. Über diese Kette lässt sich ableiten, welche Tests jetzt relevant sind.

Noch präziser wird es über das Code-Delta. Wenn seit dem letzten Lauf bestimmte Files geändert wurden und diese Files bei einer bestimmten User Story entstanden sind, sollten die Tests zu dieser User Story laufen.

Darüber liegt eine Gewichtung, die für jedes Unternehmen anders aussieht, weil sie die jeweilige Definition von Risiko abbildet. In die Gewichtung fliessen unter anderem ein:

• Kritikalität des Tests, Bugs oder der zugehörigen Story
• Wie lange der Test nicht mehr gelaufen ist
• Codequalität und Unit-Test-Coverage der betroffenen Komponente
• Änderungen an als kritisch eingestuften Codestellen

Eine businesskritische Komponente mit guter Unit-Test-Abdeckung kann am Ende ein geringeres Risiko tragen als eine unkritischere ohne diese Absicherung. Das Architekturdesign ist bewusst offen gehalten, damit sich solche Parameter frei einhängen lassen.

Mit einer Zeitbox wird daraus ein Optimierungsproblem: Welche Testkombination bringt die maximalen Risikopunkte in den verfügbaren Minuten unter? Genau das ist der gewählte Ansatz.

Visuelles Testen, das den Zustand der Applikation erkennt

Ein klassischer automatisierter Test schlägt nur fehl, wenn eine explizite Aktion oder Validierung scheitert. Ein Mensch testet anders. Ihm fällt ein invertiertes Logo auf, auch wenn das in keinem Testfall spezifiziert ist.

Implizites Visual Regression Testing bildet diesen Blick nach, ohne auf reinen Pixelvergleich zu setzen. Aus dem Screenshot einer Applikation zieht ein trainiertes Modell Rückschlüsse darauf, in welchem Zustand sich die Applikation befindet.

Diesen erkannten Zustand gleicht das Verfahren mit dem ab, was der Test gerade erwartet. Erwartet der Test den Zustand “eingeloggt, Suchseite mit befüllten Ergebnissen”, die Applikation zeigt aber visuell etwas anderes, fällt die Abweichung auf. Wo genau die Änderung liegt, lässt sich highlighten, ähnlich einer Heatmap. Das funktioniert überraschend performant.

Augmented Testing: Die Maschine unterstützt, statt zu ersetzen

Der Leitgedanke heisst Augmented Testing, nicht Wegrationalisierung. Es geht darum, den repetitiven Anteil der Arbeit zu entfernen, damit wieder Zeit für neue Tests, Experimente und höhere Qualität bleibt.

Auf Basis des implizit entstandenen Zustandsübergangsgraphen lässt sich automatisiert prüfen, ob sich eine Applikation in einem erwarteten Verhaltenskorridor bewegt. Das ersetzt keine fachlich designten Tests mit Business-Kontext, hilft aber, Lücken zu füllen oder eine Applikation im Sinne von Monkey-Testing gezielt zu attackieren.

Besonders praktisch wird das Modell beim Test-Design selbst. Eine Recommendation Engine weist darauf hin, dass ein gerade entworfener Pfad schon existiert, oder dass eine bestimmte Kombination von Schritten noch nicht abgedeckt ist. Für manuelle Tests funktioniert das wie eine Auto-Completion.

Braucht es Tester im Zeitalter von Machine Learning noch?

Ja, und das lässt sich an einer einfachen Frage festmachen. Stell dir ein zuverlässiges Sprachmodell in fünf Jahren vor und die Vorgabe, entweder alle Quality Engineers oder alle Developer durch diese Maschine zu ersetzen. Die Maschine kann beides. Wen ersetzt du?

Naja, so einen menschlichen Hüter der Qualität hätte ich schon gerne noch. Maschinen verstehen immer nur den Kontext, den man ihnen gibt. Und bei dieser Übersetzung passiert das Problem meistens schon. — Thomas Steirer

Diese Antwort fällt besonders deutlich aus, sobald Leib und Leben im Spiel sind. Gefragt ist dann jemand, der den Kontext versteht, statt ihn nur vorgesetzt zu bekommen.

Der Grund liegt tiefer als im Coding. Ein Grossteil der Fehler ist in den Anforderungen begründet, nicht in der Umsetzung. Solange am Anfang ein Mensch der Maschine sagen muss, was sie tun soll, bleibt der menschliche Blick auf Qualität der Punkt, an dem sich entscheidet, ob das Richtige gebaut wird.