Ein Test, der gestern grün war und heute rot ist, ohne dass jemand den Code angefasst hat: Das ist ein Flaky Test. Bereits 2017 zeigte Google, dass rund 16% von etwa 4,2 Millionen Tests Anzeichen von Flakiness aufwiesen (Micco/Google, 2017). Self-Healing Locators versprechen Abhilfe. Sie reparieren kaputte Element-Selektoren automatisch, wenn sich die Benutzeroberfläche ändert. Dieser Artikel erklärt, warum Flaky Tests entstehen, was sie wirklich kosten, wie Self-Healing technisch funktioniert und wo seine ehrlichen Grenzen liegen.

Kurz gefasst: Flaky Tests verschlingen messbar Zeit. Atlassian beziffert allein durch Test-Reruns über 150.000 Entwicklerstunden pro Jahr (Atlassian Engineering, 2025). Self-Healing Locators beheben realistisch ~70-85% der Fehler durch UI-Änderungen, nicht alles. Entscheidend ist, dass jede Reparatur protokolliert und nachvollziehbar bleibt.

Abbildung 1: Self-Healing Locators speichern pro Element mehrere Merkmale statt nur eines Selektors.

Was sind Flaky Tests und warum entstehen sie?

Ein Flaky Test liefert bei identischem Code und unverändertem Verhalten mal ein Bestanden, mal ein Durchgefallen. Google maß bereits 2017, dass etwa 1,5% aller Testläufe flaky waren und rund 84% der Pass-nach-Fail-Übergänge einen Flaky Test betrafen (Micco/Google, 2017). Das macht sie so heimtückisch: Sie verstecken sich zwischen echten Fehlern.

Die Ursachen sind vielfältig, doch ein Muster sticht heraus. Bei UI-Tests brechen Selektoren, sobald sich das Markup ändert. Ein umbenannter CSS-Klassenname, eine neue Verschachtelung im DOM, eine generierte ID: Schon findet der Test sein Element nicht mehr.

Die häufigsten Bruchstellen

• Brüchige Locator: XPath-Pfade oder CSS-Selektoren, die an Position oder Struktur hängen statt an stabilen Attributen.

• Timing: Asynchrone Ladevorgänge, bei denen der Test schneller ist als die Anwendung.

• Testdaten: Zustände, die nicht sauber zurückgesetzt werden, oder geteilte Umgebungen.

• Architektur: Race Conditions, Caching, instabile Drittsysteme.

Nur die erste Kategorie lässt sich durch Self-Healing Locators direkt adressieren. Das ist eine wichtige Unterscheidung, auf die wir zurückkommen.

Was kosten Flaky Tests wirklich?

Abbildung 4: Drei belegte Kennzahlen zu den Kosten von Flaky Tests.

Flaky Tests kosten konkrete Entwicklerzeit, nicht nur Nerven. Atlassian berichtet, dass Reruns allein im Jira-Backend über 150.000 Entwicklerstunden pro Jahr verschwenden, und dass Flakiness rund 21% der Frontend-Master-Build-Fehler verursacht (Atlassian Engineering, 2025). Ihre Infrastruktur verarbeitet täglich über 350 Millionen Testausführungen.

Das Problem wächst, nicht schrumpft. Laut einer Auswertung von über zehn Millionen Bitrise-Builds stieg der Anteil mobiler Teams, die auf Flaky Tests stoßen, von 10% (2022) auf 26% (2025) (SD Times/Bitrise, 2025). Diese Zahl stammt aus einer einzelnen Quelle und zeigt einen Trend, keine harte Konstante.

Eine industrielle Einzelfallstudie der TU München bezifferte den Aufwand für Reparaturen flaky Tests auf bis zu 1,28% der Entwicklerzeit, etwa 2.250 US-Dollar pro Monat für ein Team (IEEE/TU München, 2024). Das ist ein Datenpunkt, kein Branchenschnitt, aber er macht das Muster greifbar.

[UNIQUE INSIGHT] Der eigentliche Schaden ist nicht die verlorene Zeit, sondern das verlorene Vertrauen. Wenn ein Team gelernt hat, rote Tests als Rauschen abzutun, fängt die Suite echte Regressionen nicht mehr ab. Die Wartung von Tests hängt eng mit diesem Vertrauensproblem zusammen, wie wir im Beitrag zur Reduzierung der Testwartung mit KI zeigen.

Was sind Self-Healing Locators und wie funktionieren sie?

Abbildung 2: In vier Schritten von gebrochenem Selektor zur protokollierten Reparatur.

Self-Healing Locators sind Element-Selektoren, die sich automatisch reparieren, wenn der ursprüngliche Selektor nach einer UI-Änderung fehlschlägt. Statt sofort fehlzuschlagen, sucht der Mechanismus das gemeinte Element anhand mehrerer gespeicherter Merkmale neu. Diese Technik gehört zum breiteren Feld der KI-gestützten Testautomatisierung, das traditionelle Skripte um adaptive Logik erweitert.

Im Kern speichert das Tool zum Aufnahmezeitpunkt nicht nur einen Selektor, sondern ein Profil aus mehreren Attributen.

Welche Signale Self-Healing nutzt

• Mehrere Attribute: ID, Klasse, Name, Textinhalt, ARIA-Rolle, Platz im DOM-Baum.

• Relative Position: Nähe zu stabilen Nachbarelementen oder Beschriftungen.

• Visuelle Merkmale: Bei manchen Tools die ungefähre Lage und das Aussehen des Elements.

• Historie: Welche Selektoren in früheren Läufen funktioniert haben.

Bricht der primäre Selektor, gewichtet der Algorithmus die verbliebenen Signale und wählt das wahrscheinlichste Kandidatenelement. Findet er eine zuverlässige Übereinstimmung, läuft der Test weiter und der reparierte Selektor wird für künftige Läufe vorgeschlagen.

[PERSONAL EXPERIENCE] In der Praxis sehen wir den größten Nutzen bei breiten, oberflächlichen Suiten mit vielen Klick-Pfaden durch sich häufig ändernde Frontends. Dort, wo ein Frontend-Refactoring sonst hunderte Selektoren auf einen Schlag brechen würde, fängt Self-Healing den Großteil ab.

Wie viel reparieren Self-Healing Locators wirklich?

Abbildung 3: Heilbar sind nur bruechige Locator.

Realistisch beheben Self-Healing Locators etwa 70-85% der Fehlschläge, die durch UI-Änderungen entstehen, während der Rest auf Daten, Timing und Architektur zurückgeht (Virtuoso QA, 2024). Diese Spanne ist ehrlicher als die runden Marketingzahlen, die im Markt kursieren.

Anbieter berichten Wartungsreduktionen im Bereich von 80-95%, doch diese Zahlen sind nicht vergleichbar. mabl wirbt mit “bis zu 95%”, Functionize nennt 85% weniger Wartung bei 99,9% Heilungsgenauigkeit, Virtuoso/DXC berichten 83% (Functionize; Virtuoso QA, 2024-25). Jede Zahl entstand unter anderen Anwendungen, Suiten und Messmethoden.

[UNIQUE INSIGHT] Eine aggregierte “Self-Healing löst 90% aller Probleme”-Aussage wäre irreführend. Diese Zahlen messen Wartungsaufwand pro Anbieter, nicht den Anteil aller Flaky-Ursachen. Da nur die Locator-Kategorie heilbar ist, bleibt Self-Healing per Definition ein Teil der Lösung. Wer das anders darstellt, verkauft ein Versprechen, das die Technik nicht halten kann.

Die übrigen Ursachen brauchen andere Werkzeuge: bessere Wartestrategien gegen Timing-Flakiness, saubere Testdaten-Isolation, stabilere Architektur. Self-Healing ersetzt diese Arbeit nicht.

Warum muss Self-Healing protokolliert und auditierbar sein?

Self-Healing ohne Protokoll ist ein Risiko, kein Feature. Reparaturen ändern stillschweigend, was ein Test prüft, und genau hier liegt die Gefahr. Wenn der Mechanismus das falsche Element wählt, läuft der Test grün weiter, während er etwas anderes testet als beabsichtigt. Vertrauen in KI-Ergebnisse ist ohnehin angespannt: Googles DORA-Report 2025 zeigt, dass Entwickler eingesparte Zeit oft wieder ins Prüfen der KI-Ausgaben investieren (Google DORA, 2025).

Eine Black-Box-Reparatur untergräbt genau das Vertrauen, das eine Testsuite liefern soll. Deshalb braucht jede Heilung eine Spur.

Was eine vertrauenswürdige Self-Healing-Lösung protokolliert

• Was brach: Der ursprüngliche Selektor und der Grund des Fehlschlags.

• Was gewählt wurde: Das neue Element samt Konfidenz-Score.

• Wann und wo: Zeitstempel, Testlauf, Umgebung.

• Freigabe: Eine Möglichkeit für einen Menschen, die Reparatur zu bestätigen oder zu verwerfen.

Genau hier setzt Autemos an. Self-Healing Locators in Autemos sind protokolliert statt Black-Box: Jede Reparatur wird festgehalten und kann von einem Menschen freigegeben werden. Für regulierte Branchen wie Banken zählt dieser Audit-Trail mehr als ein hoher Automatisierungsgrad. Wer in der Suite nicht nachweisen kann, warum ein Test grün ist, hat in einem Audit ein Problem.

Was Flaky Tests wirklich kosten

Häufig gestellte Fragen

Was ist der Unterschied zwischen Flaky Tests und echten Fehlern?

Ein Flaky Test wechselt sein Ergebnis ohne Code- oder Verhaltensänderung, ein echter Fehler zeigt eine reale Regression. Google maß, dass rund 84% der Pass-nach-Fail-Übergänge einen Flaky Test betrafen (Micco/Google, 2017). Die Trennung gelingt am besten durch Wiederholungsläufe und Protokollierung.

Beseitigen Self-Healing Locators alle Flaky Tests?

Nein. Self-Healing adressiert nur Fehler durch UI- und Locator-Änderungen, realistisch etwa 70-85% dieser Kategorie (Virtuoso QA, 2024). Flakiness durch Timing, Testdaten oder Architektur braucht andere Lösungen wie bessere Wartestrategien und Datenisolation.

Sind die Wartungsreduktionen von 80-95% glaubwürdig?

Sie sind anbieterspezifisch und nicht vergleichbar. mabl nennt “bis zu 95%”, Functionize 85%, Virtuoso/DXC 83% (Functionize, 2024-25). Jede Zahl entstand unter anderen Bedingungen, daher sollten Sie sie als Einzelangaben lesen, nicht als Branchenwert.

Warum ist ein Protokoll bei Self-Healing wichtig?

Weil eine stille Reparatur ändern kann, was ein Test prüft, ohne dass es jemand merkt. Ohne Protokoll riskieren Sie grüne Tests, die das Falsche testen. Ein nachvollziehbarer Audit-Trail ist besonders in regulierten Branchen Pflicht, wie wir im Beitrag zur Testwartung mit KI ausführen.

Wie groß ist das Flaky-Test-Problem wirklich?

Es ist messbar und wächst. Atlassian beziffert die Verschwendung auf über 150.000 Entwicklerstunden pro Jahr allein durch Reruns (Atlassian Engineering, 2025). Bei mobilen Teams stieg die Betroffenheit von 10% auf 26% zwischen 2022 und 2025 (SD Times/Bitrise, 2025).

Fazit

Flaky Tests sind kein Randthema, sondern ein messbares Kostenproblem: Google sah schon 2017 rund 16% aller Tests betroffen, Atlassian beziffert die Verschwendung auf über 150.000 Entwicklerstunden pro Jahr. Self-Healing Locators sind ein starkes Werkzeug dagegen, aber kein Allheilmittel. Sie reparieren realistisch 70-85% der UI-bedingten Fehler, während Timing, Daten und Architektur eigene Antworten verlangen.

Der entscheidende Punkt ist nicht die höchste Heilungsquote, sondern die Nachvollziehbarkeit. Eine protokollierte, menschlich freigegebene Reparatur schützt das Vertrauen in Ihre Suite. Eine Black Box untergräbt es. Wenn Sie sehen möchten, wie auditierbares Self-Healing in der Praxis aussieht, buchen Sie eine Demo und lassen Sie sich den Audit-Trail an Ihren eigenen Tests zeigen.