Qytera ist Ihr Dienstleister für Testautomatisierung in Deutschland und der DACH-Region. Wir stabilisieren automatisierte Testsuiten, damit Ihre Pipeline verlässlich rot oder grün meldet.
Stellen Sie sich vor, Ihr Team startet die Pipeline vor dem Release. Ein Test scheitert. Sie starten ihn erneut, ohne eine Zeile zu ändern, und er besteht. Genau das ist ein Flaky Test: ein Test, dessen Ergebnis zwischen bestanden und gescheitert schwankt, obwohl sich weder Code noch Testfall geändert haben. Solche Tests kosten Zeit, untergraben das Vertrauen in die Suite und verstecken echte Fehler.
Was sind Flaky Tests?
Ein Flaky Test liefert bei identischem Code und identischem Testfall nicht reproduzierbare Ergebnisse. Mal ist er grün, mal rot, abhängig von Faktoren, die der Test nicht kontrolliert. Die Flake-Rate beschreibt den Anteil der Läufe, in denen ein Test ohne echte Ursache scheitert.
Der Kern des Problems ist fehlende Determiniertheit. Ein guter automatisierter Test ist deterministisch: gleiche Eingabe, gleiches Ergebnis. Ein Flaky Test verletzt diese Regel, meist durch versteckte Abhängigkeiten von Zeit, Reihenfolge, Testdaten oder Infrastruktur.
Inhaltsverzeichnis
- Was sind Flaky Tests?
- Warum Flaky Tests teuer sind
- Die häufigsten Ursachen für Flaky Tests
- Flaky Tests erkennen und messen
- Flaky Tests beheben: konkrete Strategien
- Tool-Unterstützung gegen Flakiness
- Flaky Tests in der Regressionssuite
- Eine Flaky-Test-Policy für Ihr Team
- Fazit
- Häufige Fragen zu Flaky Tests
Warum Flaky Tests teuer sind
Instabile Tests verursachen drei konkrete Schäden:
- Verlorene Zeit: Jeder erneute Pipeline-Lauf bindet Minuten pro Entwickler und blockiert das Deployment. Bei zehn Läufen pro Tag summiert sich das schnell auf Stunden pro Woche.
- Verlorenes Vertrauen: Wenn ein Team gelernt hat, rote Tests einfach neu zu starten, ignoriert es irgendwann auch echte Fehler. Die Suite verliert ihren Zweck.
- Versteckte Defekte: Ein Test, der zufällig grün wird, kann einen realen Fehler überdecken. Flakiness ist damit nicht nur ein Ärgernis, sondern ein Qualitätsrisiko.
Faustregel aus der Praxis: Ab einer Flake-Rate von rund einem Prozent beginnt ein Team, Ergebnissen zu misstrauen. Ab fünf Prozent ist die Suite als Freigabe-Signal praktisch wertlos.
Die häufigsten Ursachen für Flaky Tests
Timing und feste Wartezeiten
Die häufigste Ursache sind feste Wartezeiten wie sleep(2000). Sie raten die Ladezeit einer Anwendung. Ist der Server einmal langsamer, scheitert der Test, obwohl die Anwendung korrekt arbeitet. Feste Wartezeiten sind entweder zu kurz und erzeugen Flakiness oder zu lang und verschwenden Zeit.
Testabhängigkeiten und Reihenfolge
Tests, die aufeinander aufbauen, sind fragil. Wenn Test B die Daten von Test A voraussetzt, scheitert B, sobald A ausfällt oder die Reihenfolge sich ändert. Bei paralleler Ausführung wird dieses Problem sofort sichtbar.
Gemeinsamer Zustand und Testdaten
Zwei Tests, die denselben Datensatz anlegen, ändern oder löschen, stören sich gegenseitig. Ein nicht zurückgesetzter Zustand aus einem früheren Lauf führt zu scheinbar zufälligen Fehlern.
Umgebung und Infrastruktur
Unterschiede zwischen lokaler Umgebung und CI-Server, langsame Netzwerke, überlastete Test-Container oder wechselnde Browser-Versionen erzeugen Flakiness, die auf dem eigenen Rechner nicht auftritt.
Externe Dienste
Jeder echte Aufruf einer fremden API, Datenbank oder eines Zahlungsdienstes bringt dessen Verfügbarkeit und Latenz in Ihren Test. Ist der externe Dienst kurz nicht erreichbar, scheitert Ihr Test ohne eigene Schuld.
Nebenläufigkeit und Race Conditions
Wenn ein Test eine Aktion auslöst und sofort das Ergebnis prüft, ohne auf den Abschluss zu warten, entsteht ein Wettlauf zwischen Anwendung und Prüfung. Mal gewinnt die eine, mal die andere Seite.
Animationen und dynamische Oberflächen
UI-Animationen, verzögert nachladende Elemente und wechselnde Element-Positionen führen dazu, dass ein Klick ins Leere geht oder ein Element noch nicht sichtbar ist.
Flaky Tests erkennen und messen
Sie können nur stabilisieren, was Sie messen. Drei Schritte helfen:
- Flake-Rate erfassen: Lassen Sie Tests wiederholt gegen denselben Code laufen, etwa nächtlich 20 Läufe. Tests, die nicht immer dasselbe Ergebnis liefern, sind Flaky-Kandidaten.
- Retries als Diagnose, nicht als Lösung: Ein automatischer Wiederholungslauf zeigt, welche Tests nur beim zweiten Versuch bestehen. Nutzen Sie diese Information zur Priorisierung, nicht zum Verstecken. Ein Test, der dauerhaft auf Retry angewiesen ist, bleibt kaputt.
- Quarantäne statt Löschen: Verschieben Sie einen bekannten Flaky Test in eine separate Quarantäne-Gruppe. Er blockiert dann nicht die Pipeline, bleibt aber sichtbar und wird nachverfolgt, statt still zu verschwinden.
Ergänzen Sie ein Reporting, das die Flake-Rate pro Test über die Zeit zeigt. So erkennen Sie Trends, bevor die Suite unbrauchbar wird.
Flaky Tests beheben: konkrete Strategien
Explizite statt fester Wartezeiten
Ersetzen Sie feste Wartezeiten durch Bedingungen, die auf einen konkreten Zustand warten, etwa auf die Sichtbarkeit eines Elements oder den Abschluss eines Netzwerkaufrufs. Der Test wartet dann genau so lange wie nötig und nicht länger.
Testisolation
Jeder Test legt seine eigenen Daten an, prüft und räumt danach auf. Kein Test darf sich auf das Ergebnis eines anderen verlassen. Nur so laufen Tests verlässlich parallel und in beliebiger Reihenfolge.
Deterministische Testdaten
Erzeugen Sie Testdaten frisch pro Lauf, statt auf einen geteilten Bestand zuzugreifen. Ein eindeutiger Schlüssel pro Testlauf verhindert Kollisionen bei paralleler Ausführung.
Externe Dienste simulieren
Simulieren Sie fremde Schnittstellen über Service-Virtualisierung oder Mock-Server, zum Beispiel mit WireMock oder msw. Ihr Test prüft dann Ihr eigenes Verhalten und nicht die Verfügbarkeit eines Drittsystems.
Auf den richtigen Zustand warten
Prüfen Sie ein Ergebnis erst, wenn die Anwendung die Aktion nachweislich abgeschlossen hat. Moderne Frameworks bieten dafür ein automatisches Warten auf Elemente und Netzwerk-Ruhe.
Tool-Unterstützung gegen Flakiness
| Werkzeug | Beitrag zur Stabilität |
|---|---|
| Playwright | Automatisches Warten auf Elemente, Trace-Viewer zur Fehleranalyse, konfigurierbare Retries pro Projekt |
| Cypress | Automatische Wiederholung von Prüfungen bis zum Timeout, Test-Retries, klare Fehlermeldungen mit Snapshot |
| JUnit und pytest | Testisolation über Fixtures, deterministische Setup- und Teardown-Phasen |
| WireMock und msw | Service-Virtualisierung für stabile, schnelle Tests ohne echte Fremdaufrufe |
| CI-Dashboards | Flake-Rate-Reporting und Trend-Analyse über Jenkins oder GitHub Actions |
Vertiefung in unseren Praxis-Guides zu Playwright und Cypress.
Flaky Tests in der Regressionssuite
Regressionssuiten wachsen mit jedem Sprint. Genau dort schadet Flakiness am meisten: Je größer die Suite, desto höher die Wahrscheinlichkeit, dass mindestens ein Test ohne echten Grund scheitert. Eine stabile Regressionssuite ist die Voraussetzung dafür, dass Sie häufig releasen können, ohne jedem roten Lauf hinterherzujagen.
Wie Sie Regressionstests auswählen, automatisieren und in die Pipeline einbinden, zeigt unser Praxis-Guide zum Regressionstest.
Eine Flaky-Test-Policy für Ihr Team
Technik allein reicht nicht. Erfolgreiche Teams vereinbaren klare Regeln:
- Kein Merge auf grün durch Retry: Ein Test, der nur nach Wiederholung besteht, gilt als rot.
- Quarantäne mit Frist: Ein Flaky Test wandert in Quarantäne und bekommt ein Ticket mit fester Frist zur Behebung, zum Beispiel fünf Arbeitstage.
- Test-Pflege als feste Aufgabe: Tests werden gemeinsam mit dem Code weiterentwickelt. Reservieren Sie pro Sprint Kapazität für die Pflege der Suite.
Weitere Prinzipien finden Sie in unseren 6 goldenen Regeln der Testautomatisierung.
Fazit
Flaky Tests sind kein Schicksal, sondern ein lösbares Problem fehlender Determiniertheit. Wer die Ursachen kennt, feste Wartezeiten durch explizite Bedingungen ersetzt, Tests isoliert, Testdaten deterministisch hält und externe Dienste simuliert, bekommt eine Suite, der das Team wieder vertraut. Der wichtigste Hebel ist der kulturelle: Ein roter Test wird behoben, nicht neu gestartet.
Sie planen eine stabile Testautomatisierung oder Ihre Suite meldet zu oft falschen Alarm? Wir stabilisieren automatisierte Tests und Pipelines. Testautomatisierung Beratung anfragen.
Häufige Fragen zu Flaky Tests
Was ist ein Flaky Test?
Ein Flaky Test liefert bei identischem Code und identischem Testfall mal ein bestandenes und mal ein gescheitertes Ergebnis. Die Ursache liegt nicht im Testfall selbst, sondern in versteckten Abhängigkeiten von Zeit, Reihenfolge, Testdaten oder Infrastruktur.
Was sind die häufigsten Ursachen für Flaky Tests?
Am häufigsten sind feste Wartezeiten statt expliziter Bedingungen, Abhängigkeiten zwischen Tests, gemeinsam genutzte Testdaten, instabile Umgebungen, echte Aufrufe externer Dienste und Race Conditions zwischen Aktion und Prüfung.
Wie erkenne ich Flaky Tests?
Lassen Sie Tests wiederholt gegen unveränderten Code laufen, zum Beispiel 20 Läufe pro Nacht. Tests, die nicht immer dasselbe Ergebnis liefern, sind Flaky-Kandidaten. Ein Reporting der Flake-Rate pro Test macht den Trend über die Zeit sichtbar.
Sind Retries eine Lösung für Flaky Tests?
Nein. Automatische Wiederholungen sind ein Diagnosewerkzeug, keine Lösung. Sie zeigen, welche Tests instabil sind. Ein Test, der dauerhaft auf Retry angewiesen ist, bleibt defekt und muss behoben werden.
Wie behebe ich Flaky Tests in Playwright?
Nutzen Sie das automatische Warten auf Elemente statt fester Wartezeiten, isolieren Sie jeden Test mit eigenen Daten, simulieren Sie externe Dienste und analysieren Sie Fehlläufe mit dem Trace-Viewer. Konfigurierte Retries dienen der Diagnose, nicht dem Verstecken.
Ab welcher Flake-Rate wird es kritisch?
Ab rund einem Prozent beginnt ein Team, Ergebnissen zu misstrauen. Ab fünf Prozent ist die Suite als Freigabe-Signal praktisch wertlos. Ziel ist eine Flake-Rate nahe null.