Fehleranalyse in der Testautomatisierung

15. Okt.

5 Min. Lesezeit

Beitragsbild „Grün heißt nicht gelöst" mit Gegenüberstellung von 500 Fehlschlägen und 12 tatsächlichen Ursachen_Fehleranalyse Testautomatisierung

Im letzten Beitrag dieser Serie haben wir angekündigt, die systematische Fehleranalyse vertieft zu behandeln, von der Kategorisierung nach Ursache bis zu konkreten Methoden wie Root-Cause-Analyse. Genau darum geht es in diesem Beitrag.

Ein fehlgeschlagener Test zeigt zunächst nur, dass etwas nicht wie erwartet funktioniert hat, nicht, warum. Dieser Beitrag beschreibt vier Bausteine, die diese Frage auf unterschiedlichem Maßstab beantworten:

die Root-Cause-Analyse als Grundprinzip
eine praktische Anleitung für den einzelnen fehlgeschlagenen Test
Test-Observability als systematische Instrumentierung
KI-gestütztes Failure Clustering, wenn nicht ein einzelner, sondern hunderte Tests gleichzeitig fehlschlagen

Ein abschließender Bonus-Abschnitt zu Test Smells zeigt, woran diese Analyse in der Praxis oft schon vorher scheitert: am Testcode selbst.

Root-Cause-Analyse als Grundprinzip

Root-Cause-Analyse (RCA) bezeichnet kein einzelnes Verfahren, sondern das Grundprinzip, aus dem sich die folgenden, praktischeren Ansätze ableiten: die eigentliche Ursache eines Problems zu finden, statt nur sein Symptom zu beseitigen. Ein „Causal Factor“ trägt zu einem Ergebnis bei, verhindert aber bei seiner Beseitigung kein Wiederauftreten; die Root Cause tut das.

Klassischerweise umfasst RCA vier Schritte: das Problem klar beschreiben, den zeitlichen Ablauf bis zum Auftreten rekonstruieren, ursächliche von begleitenden Faktoren unterscheiden und die Kausalbeziehung nachvollziehbar abbilden.

Der Unterschied zur reinen Symptombehandlung lässt sich an einem Testautomatisierungsbeispiel zeigen: Ein Flaky-Test, der so oft neu gestartet wird, bis er grün ist, behebt das Symptom. Erst die Suche nach der eigentlichen Ursache, etwa einer Race Condition durch fehlendes Warten auf einen asynchronen Ladevorgang, verhindert, dass der Test erneut fehlschlägt. Der folgende Abschnitt übersetzt dieses Prinzip in eine konkrete Anleitung für genau diesen Einzelfall.

Was tun, wenn ein Test fehlschlägt: eine praktische Anleitung

Für den Einzelfall lässt sich RCA in einen konkreten Ablauf übersetzen. Der API-Testing-Anbieter Apidog beschreibt dazu in einem Praxisbeitrag (kein wissenschaftlicher Text, aber eine brauchbare Checkliste) sinngemäß folgende Schritte:

Zunächst die Fehlermeldung und den Stacktrace genau lesen und erwartetes mit tatsächlichem Ergebnis vergleichen, bei Bedarf auch anhand von Screenshots.
Dann die Schritte manuell nachvollziehen, um zu klären, ob tatsächlich die Anwendung fehlerhaft ist oder der Test selbst falsch geschrieben wurde.
Anschließend den Kontext prüfen: kürzliche Code-Commits, Abhängigkeits-Updates, Konfigurationsänderungen oder Datenbankschema-Anpassungen, die zeitlich zum Fehlschlag passen.
Danach das Testskript selbst kontrollieren. Häufige Ursachen im Test selbst sind Syntaxfehler, falsche oder fehlende Assertions, Race Conditions, hartkodierte Werte oder veraltete Element-Locators.
Erst danach die Testumgebung prüfen (Konfiguration, Netzwerk, Datenbankstatus, Browserkompatibilität) und den Test mehrfach beziehungsweise in einer anderen Umgebung wiederholen, um Flakiness von einem echten, reproduzierbaren Fehler zu unterscheiden.
Am Ende steht die Dokumentation: ein aussagekräftiger Testname, ein kurzer Kommentar zur Ursache und die Abstimmung mit den zuständigen Entwickler*innen, statt den Fehlschlag stillschweigend zu ignorieren oder den Test einfach zu deaktivieren.

Dieser Ablauf funktioniert gut für einen einzelnen Test. Wenn aber hunderte gleichzeitig fehlschlagen, wird er ohne die im Folgenden beschriebene Instrumentierung schnell unpraktikabel.

Test-Observability: die Datengrundlage für die Analyse

Damit die Schritte aus der Anleitung oben nicht bei jedem Fehlschlag von vorn beginnen (Fehlermeldung suchen, Kontext zusammentragen, Umgebung prüfen), braucht es eine systematische Datengrundlage.

Test-Observability bezeichnet genau das: die Fähigkeit, nicht nur zu sehen, dass ein Test fehlgeschlagen ist, sondern auch zu verstehen, was währenddessen passiert ist und warum. Dafür werden Logs, Metriken, Traces und Ausführungsdaten zu einem zusammenhängenden Bild verbunden, statt als verstreute Einzelwerte in unterschiedlichen Werkzeugen liegen zu bleiben. Nach BrowserStack lässt sich das in drei Säulen unterteilen:

Logs als ereignisbezogene Aufzeichnungen (Fehler, Warnungen, Request-Details, Stacktraces) und meist erste Anlaufstelle für die genaue Fehlersequenz
Metriken wie Antwortzeit, Fehlerrate oder Durchsatz, die Muster über mehrere Testläufe hinweg sichtbar machen
Traces, die den Weg einer Anfrage durch mehrere Systemkomponenten zeigen und damit besonders in Microservice-Architekturen helfen, das verantwortliche Teilsystem einzugrenzen.

Der Nutzen für die Fehleranalyse liegt darin, dass Ursachenfindung nicht mehr bedeutet, nacheinander mehrere getrennte Tools zu durchsuchen, sondern auf bereits verknüpfte Daten zuzugreifen. Das hilft besonders bei Flaky-Tests, wo sich ein wiederkehrendes Muster oft erst über historische Daten mehrerer Läufe zeigt.

Der Aufbau hat allerdings einen Preis: Instrumentierung, Datenmenge und Speicherkosten steigen. Und ohne sinnvoll gesetzte Schwellenwerte drohen so viele Alarme, dass sie ihren Zweck verfehlen.

Test-Observability ist damit die Dateninfrastruktur, auf der die im nächsten Abschnitt beschriebene automatisierte Auswertung überhaupt erst aufsetzen kann: Failure Clustering etwa verwendet genau die Signale (Fehlertext, Stacktrace, Timing), die eine solche Instrumentierung liefert.

KI-gestütztes Failure Clustering

Bricht eine gemeinsame Abhängigkeit weg (ein Auth-Service, eine Datenbankmigration, eine geänderte Selektor-ID), schlagen oft hunderte Tests gleichzeitig fehl, obwohl es nur eine Ursache gibt. Failure Clustering fasst solche Fehlschläge automatisiert zu Gruppen mit vermutlich gemeinsamer Ursache zusammen.

Die Gruppierung erfolgt nicht anhand exakter Fehlertext-Übereinstimmung, sondern anhand mehrerer Signale:

normalisierter Fehlertext
Stacktrace
die tatsächlich geprüfte Assertion
zeitliches Zusammentreffen über mehrere Testläufe
historische Korrelation: ob eine Gruppe schon einmal gemeinsam fehlgeschlagen ist und ob das damals real oder flaky war

Illustrativ (kein fester Wert, abhängig von der jeweiligen Suite) verdichten sich so beispielsweise 500 Einzelfehlschläge auf etwa 12 tatsächliche Ursachen. Die Triage erfolgt dann pro Cluster statt pro Test: dieselbe Schritt-für-Schritt-Anleitung von oben, nur einmal pro Cluster statt einmal pro Test durchgeführt.

Der Ansatz verbindet sich unmittelbar mit der Flaky-Test-Erkennung: Ein Cluster wiederkehrender, unregelmäßiger Fehlschläge ohne zugehörige Codeänderung ist ein starkes Flaky-Signal. Laut Google Testing Blog zeigen rund 16 Prozent aller Tests bei Google irgendeine Form von Flakiness.

Die Quelle zu diesem Ansatz ist ein Hersteller-Blog (Qualflare). Die zugrundeliegende Idee, Fehlschläge nach Ursache statt nach Testname zu gruppieren, lässt sich aber unabhängig vom konkreten Anbieter nachvollziehen. Wie zuverlässig das in der Praxis gelingt, hängt allerdings von etwas ab, das keine der bisher genannten Methoden beeinflussen kann: der Qualität des Testcodes selbst.

Bonus: Test Smells – wenn der Testcode selbst die Analyse erschwert

Test Smells sind ein „schlampiger Programmierstil“ im Testcode, wie es das Austrian Testing Board definiert. Die negativen Auswirkungen zeigen sich dabei nicht an der Anwendung, sondern an der Wartbarkeit und Verständlichkeit der Tests selbst. Sie erklären, warum Fehleranalyse in der Praxis oft schwerer ist, als sie sein müsste, unabhängig davon, ob man sie von Hand oder automatisiert betreibt.

Fünf Beispiele:

Ein Anonymous Test trägt einen Namen wie „test1“ und verrät nichts über seinen Zweck. Beim Fehlschlag muss man erst den Code lesen, um zu verstehen, was überhaupt geprüft wurde.
Assertion Roulette liegt vor, wenn eine Testmethode mehrere Assert-Anweisungen ohne Beschriftung enthält. Wenn der Test dann fehlschlägt, muss man erst mühsam herausfinden, welche der Prüfungen eigentlich nicht bestanden hat.
Conditional Test Logic, also If-else-Verzweigungen oder Schleifen im Test selbst, erhöht die Komplexität und damit den Aufwand, den Fehlschlag nachzuvollziehen.
Ein Rotten Green Test ist der gefährlichste Fall: Eine Assertion liegt in einem Codepfad, der zur Laufzeit nie erreicht wird. Der Test ist grün, ohne dass je etwas geprüft wurde, ein Fehler, der so nie auffällt.
Ein Long Test mit mehr als etwa 30 Anweisungen macht schon das Lesen selbst zur Aufgabe. Das gilt unabhängig vom gewählten Maßstab: Ein unklar geschriebener Test erschwert beides gleichermaßen, die manuelle Anleitung von oben genauso wie die automatisierte Auswertung durch Observability-Daten und Failure Clustering.

Fazit

Root-Cause-Analyse ist dabei kein vierter Baustein neben den anderen drei, sondern das Prinzip, dem alle drei folgen: nicht das Symptom zu beheben, sondern die Ursache zu finden.

Für die Praxis heißt das: Kleine Testsuiten brauchen vor allem eine saubere Analyse im Einzelfall und guten Testcode. Dafür reicht die praktische Anleitung von oben meist völlig aus. Mit wachsender Suitengröße werden Observability und automatisiertes Clustering relevanter, weil sich Fehlschläge dann nicht mehr einzeln durchgehen lassen. Kein Team muss deshalb bei allen drei Bausteinen gleichzeitig anfangen.

Was sich dabei nicht verschieben lässt, ist die Qualität des Testcodes selbst: Ein Test Smell verlangsamt die manuelle wie die automatisierte Variante gleichermaßen.

Sie möchten die Fehleranalyse in Ihrer eigenen Testautomatisierung systematischer aufsetzen? In einem unverbindlichen Austausch schauen wir uns das gemeinsam an.

Kontaktieren Sie uns unter: office@gruener-it.at