Flaky Tests: Warum sie auftreten und wie man sie behebt

Ihre CI-Pipeline wird rot, jemand klickt auf „Erneut ausführen”, und der Build kommt beim zweiten Versuch grün zurück. Der PR wird gemergt, und niemand fragt, warum der Test beim ersten Mal fehlgeschlagen ist, weil das Team die Antwort schon parat hat: „Er war flaky.” Wenn das einmal pro Woche passiert, haben Sie ein Problem, das einen Namen verdient.

Flaky Tests sind automatisierte Prüfungen, die bestehen und fehlschlagen, ohne dass jemand den Code anfasst. Sie wirken harmlos, weil jeder einzelne Neustart grün endet, aber sie sind der Moment, in dem Ihre QA aufhört, ein Qualitätssignal zu sein, und anfängt, Rauschen zu sein, das Ihr Team zu ignorieren lernt. Sie tauchen auf dieselbe Weise auf wie die inkonsistenten Ausgaben, die das Nutzervertrauen in KI-Systeme untergraben, und das zugrundeliegende Problem ist dasselbe: Wenn Ergebnisse nicht vorhersagbar sind, hören die Menschen auf, ihnen zu vertrauen.

In diesem Artikel führen wir Sie durch die tatsächlichen Kosten von Flaky Tests für Ihr Team, warum sie auftreten, wie man sie ordentlich behebt und wie man sie von Anfang an aus der Suite fernhält.

Wie Testunzuverlässigkeit Ihrem Team schadet

Der Schaden durch Test-Flakiness ist selten ein einzelnes dramatisches Versagen. Er akkumuliert sich langsam, und die meisten Teams bemerken es erst nach monatelangem Verfall. Laut dem Capgemini World Quality Report 2025-26 kämpfen jetzt 60 % der Organisationen mit sicheren, skalierbaren Testdaten, was eines der Fundamente ist, auf denen Flakiness aufbaut.

Hier ist, was Flakiness einem Team über die Zeit tatsächlich antut:

Echte Bugs verstecken sich hinter abgewiesenen Fehlern. Wenn der erste Instinkt des Teams bei einem roten Build „wahrscheinlich flaky, nochmal starten” lautet, trainieren sie sich selbst, Fehler zu ignorieren – und echte Regressionen schlüpfen mit demselben Schulterzucken durch.
Der Neustart-Reflex ersetzt die Untersuchung. Entwickler klicken auf Neustart, bis der Build grün ist, und mergen dann – sodass die Test-Suite aufhört, als Qualitätsgatter zu funktionieren, und anfängt, als Münzwurf mit zusätzlichen Schritten zu wirken.
Releases verlieren ihr Vertrauen. Entweder verzögern Sie einen Release, während jemand entwirrt, ob ein Fehler echt ist, oder Sie liefern und hoffen – und keiner der Ansätze skaliert mit dem Wachstum Ihres Produkts. Eine zuverlässige Test-Suite ist das, was Pre-Release-Vertrauen überhaupt erst ermöglicht.
Ein schlechter Test infiziert den Rest. Sobald Ihr Team aufhört, einem Test zu vertrauen, beginnt es, die gesamte Suite in Frage zu stellen – und zuverlässige Tests bekommen dasselbe Schulterzucken wie flaky.
Onboarding leidet. Neue Entwickler können nicht unterscheiden, welche Fehler wichtig sind, und fragen daher immer wieder nach – und schlimmer noch, sie übernehmen den Neustart-Reflex am ersten Tag und tragen ihn weiter.

Eine Test-Suite ist nur so wertvoll wie das Vertrauen, das Ihr Team in sie setzt – und dieses Vertrauen ist das Gut, das Flakiness am meisten untergräbt. Dies ist das schwelende Qualitätsproblem, das wir für sich schnell bewegende Teams durch unsere Regressionstesting-Services entwirren, bei denen die Stabilität der Suite der eigentliche Punkt ist.

Flaky Tests: Warum sie auftreten und wie man sie wirklich behebt

Warum Flaky Tests auftreten: Fünf echte Ursachen

Die meisten Unzuverlässigkeiten lassen sich auf eine von fünf Ursachen zurückführen. Zu wissen, mit welcher Ursache man es zu tun hat, ist schon die halbe Lösung. Die andere Hälfte besteht darin, dem Drang zu widerstehen, den Test erneut auszuführen und zu hoffen, dass er diesmal erfolgreich ist. Teams, die die Diagnose überspringen, enden mit einer Testsuite, der niemand vertraut, und einem fehlgeschlagenen Build, den alle zu ignorieren lernen.

Timing und Synchronisation

Der Test bewegt sich schneller als die App. Er klickt auf eine Schaltfläche und prüft sofort das Ergebnis, aber die App lädt noch – und eine Bestätigungsmeldung, die 200 Millisekunden zum Rendern braucht, ist nicht da, wenn Ihr Test bei 50 ms prüft. Die Gesprächsanalogie passt gut: Es ist wie „Hast du mich gehört?” zu fragen, bevor die andere Person fertig gesprochen hat. Timing-Probleme sind die häufigste Ursache für Flakiness in jedem Framework und jeder Sprache.

Unterschiede in der Testumgebung

Der Laptop Ihres Entwicklers hat mehr RAM, eine schnellere Festplatte und eine stabile Netzwerkverbindung. Ihr CI-Runner ist geteilt, langsamer und ressourcenbeschränkt – sodass ein Test, der auf einem Premium-Laptop in 2 Sekunden läuft, in einem kleinen CI-Container 5 Sekunden dauern kann. Der Code ist in Ordnung, die Umgebung nicht – und deshalb stirbt der Witz „funktioniert auf meinem Rechner” nie.

Tests, die sich nicht selbst aufräumen

Ein gut verhaltender Test richtet seine eigenen Daten ein, führt seine Prüfung durch und hinterlässt das System so, wie er es vorgefunden hat. Wenn ein Test einen Datensatz in der Datenbank erstellt und vergisst, ihn zu löschen, läuft der nächste Test gegen einen verschmutzten Zustand. Manchmal passiert nichts, aber manchmal schlägt der nächste Test auf subtile Weise fehl, was wie Flakiness aussieht und tatsächlich ein Hygieneproblem ist. Diese Kategorie taucht meist nur auf, wenn Tests in einer anderen Reihenfolge oder parallel ausgeführt werden.

Tests, die voneinander abhängen

Dieser ist eng verwandt und genauso häufig. Test B hängt still von etwas ab, was Test A getan hat, aber niemand hat die Abhängigkeit dokumentiert – sodass das Ausführen in einer anderen Reihenfolge Test B fehlschlagen lässt. Moderne CI-Systeme randomisieren oft die Test-Reihenfolge oder führen Tests parallel aus, was genau dann ist, wenn diese unsichtbaren Abhängigkeiten sichtbar werden. Das Team denkt, Test B sei flaky – aber das ist er nicht. Er hatte nur einen Mitbewohner, den er nie deklariert hat.

Externe Dienste, auf die der Test angewiesen ist

Tests, die echte APIs, Drittanbieter-Dienste oder Live-Datenbanken treffen, erben jedes Problem, das diese Dienste haben. Ein Netzwerk-Aussetzer, ein Rate-Limit oder eine langsame Antwort von einem Partner bedeutet, dass Ihr Test fehlschlägt – ohne dass Sie etwas dafür können. Der Test hat nicht wirklich Ihre Software getestet, er hat das Internet an einem Dienstagmorgen getestet. Die offizielle Microsoft-Learn-Dokumentation zu Azure Pipelines macht denselben Punkt: Tests können aus Gründen flaky sein, die von einfachen Timing-Problemen bis hin zu komplexen Abhängigkeiten von externen Umgebungen reichen.

Wenn sich Ihr Team stark auf Automatisierung stützt, ist die Entscheidung, was automatisiert und wie stabil es gehalten werden soll, eine strategische Entscheidung, keine technische. Wir behandeln die Prinzipien in unserer Testautomatisierungs-Praxis.

So behebt man Flaky Tests (ohne es schlimmer zu machen)

Wenn Sie sich endlich mit einem echten Flaky Test befassen, ist die Reihenfolge der Operationen wichtiger als die technische Tiefe. Hier ist, wie man Flaky Tests behebt, ohne das Problem versehentlich zu verschlimmern – in fünf Schritten, auf die wir empfehlen, Ihr Team zu verpflichten.

Bestätigen Sie, dass er tatsächlich flaky ist. Führen Sie den Test 20 bis 30 Mal unter denselben Bedingungen aus. Wenn er einmal in 30 Durchläufen fehlschlägt, ist er flaky – wenn er aber konsistent fehlschlägt, ist er kaputt, was ein anderes und schneller lösbares Problem ist.
Beheben Sie es nicht durch Hinzufügen von mehr Zeit. Die häufigste Amateur-Lösung ist das Erhöhen eines Timeouts oder das Hinzufügen eines fixen Wartezustands. Das maskiert das Problem in der Regel, anstatt es zu lösen, und der Test wird trotzdem irgendwann fehlschlagen – nur seltener, was das schlechtestmögliche Ergebnis ist, weil es die nächste Untersuchung weiter in die Zukunft verschiebt.
Finden Sie die eigentliche Grundursache. Ordnen Sie den Fehler einer der fünf Kategorien oben zu. Ist es ein Timing-Problem, ein Umgebungsunterschied oder Test-Verschmutzung? Jede Ursache hat eine andere Lösung, und die falsche anzuwenden, vergeudet den Nachmittag aller.
Beheben Sie die Ursache, nicht das Symptom. Ein flaky Timing-Test braucht kein längeres Timeout, er muss auf eine spezifische Bedingung warten. Ein verschmutzter Test braucht keine bessere Bereinigungslogik in diesem Test, er braucht den vorherigen Test, der sich selbst aufräumt.
Überprüfen Sie die Lösung. Führen Sie den Test 50 bis 100 Mal nach der Lösung aus. Wenn er nie fehlschlägt, ist die Lösung echt – wenn er noch gelegentlich fehlschlägt, haben Sie ein Symptom und keine Ursache gefunden, also zurück zu Schritt 3.

Die gesamte Abfolge klingt einfach, und das ist sie auch. Der Grund, warum die meisten Teams sie überspringen, ist, dass Flakiness-Untersuchungen mühsam sind, während der unmittelbare Druck, den PR zu mergen, direkt vor aller Augen liegt.

So vermeidet man Flaky Tests von vornherein

Prävention ist unspektakuläre Arbeit. Sie ist auch der Grund, warum manche Teams stabile Suites haben und andere Montagnachmittage mit Triage verbringen. Hier ist, wie man Flaky Tests vermeidet, bevor sie in Ihre Codebasis gelangen – formuliert als Richtlinien, auf die ein Manager ein Team verpflichten kann, nicht als Tipps, die ein Entwickler ignorieren kann.

Behandeln Sie Flakiness ab dem ersten Tag als Bug. Der Tag, an dem ein Test flaky wird, ist der Tag, an dem jemand ihn untersucht – nicht der nächste Sprint und nicht „wenn wir Zeit haben”. Wenn Sie einmal einen durchrutschen lassen, haben Sie dem Team signalisiert, dass Flakiness akzeptabel ist.
Machen Sie jeden Test eigenständig. Jeder Test sollte seine eigenen Daten einrichten, seine Prüfung durchführen und sich selbst aufräumen – ohne gemeinsame Konten, gemeinsame Datensätze oder stille Abhängigkeiten davon, was vorher gelaufen ist. Dieses einzelne Prinzip beseitigt zwei der fünf Ursachen vollständig.
Passen Sie Ihre Testumgebung an Ihre CI-Umgebung an. Wenn Ihr Team Tests auf Premium-Laptops schreibt und sie in beschränkten CI-Runnern ausführt, ist Umgebungs-Flakiness garantiert – und kein noch so cleverer Code wird sie beheben. Diese Disziplin frühzeitig einzuführen ist noch wichtiger, wenn Sie Shift-Left-Testing verfolgen, bei dem das Erkennen von Problemen in der richtigen Phase die meiste Zeit spart.
Verwenden Sie intelligente Wartezustände, keine fixen. Tests sollten auf das richtige Ereignis warten, nicht auf eine festgelegte Zeit – und ein Wartezustand von 5 Sekunden ist keine Lösung. Es ist ein verzögerter Fehler mit einem freundlichen Gesicht. Dies ist das einzige Präventionsprinzip mit der größten Wirkung, und das, bei dem die meisten Teams einen Fehler machen.
Lassen Sie Tests das echte Internet nicht berühren. Tests, die Live-APIs oder Drittanbieter-Dienste aufrufen, werden irgendwann flaky sein, weil Dienste ausfallen, Rate-Limits verhängen oder ihr Verhalten auf eigenem Zeitplan ändern. Ersetzen Sie diese Aufrufe durch kontrollierte Stellvertreter, damit der Test nur von Dingen abhängt, die Ihr Team kontrollieren kann.
Machen Sie Stabilität zu einem Code-Review-Anliegen. Ein neuer Test, der bereits flaky ist, sollte nicht gemergt werden dürfen – Stabilität ist kein Nachgedanke. Sie ist Teil der Definition von „fertig”.

Sollten Sie quarantänisieren, beheben oder löschen?

Einen Flaky Test aus der Hauptsuite herauszunehmen, damit er keine Releases mehr blockiert, nennen die meisten Teams Quarantäne. Es ist als vorübergehende Maßnahme nützlich – und keine Lösung. Quarantänisierte Tests ohne Eigentümer und Deadline werden zu einem Friedhof, den niemand liest und niemand behebt.

Bevor Sie entscheiden, stellen Sie sich drei ehrliche Fragen:

Deckt dieser Test echtes Geschäftsrisiko ab? Wenn nicht, senken Sie die Priorität und hören Sie auf, so zu tun, als wäre es dringend.
Wird dasselbe Szenario durch einen anderen, zuverlässigeren Test abgedeckt? Wenn ja, brauchen Sie diesen vielleicht überhaupt nicht.
Kostet das Beheben mehr als das Neuschreiben auf einer anderen Ebene? Manchmal ist die richtige Antwort: löschen und von vorne anfangen.

Welchen Prozess Sie auch wählen – das schlimmste Ergebnis ist das stille Mittelfeld, wo ein Test vor sechs Monaten quarantänisiert wurde und alle ihn ignorieren, während niemand ihn besitzt. Das ist keine Lösung. Es ist eine aufgeschobene Entscheidung in den Kleidern einer Lösung – und Ihre Test-Suite trägt das Gewicht jeder einzelnen davon.

Tests, die sich schlecht verhalten?

Eine Test-Suite ist nur so nützlich wie das Vertrauen, das Ihr Team in sie setzt – und Test-Flakiness ist der Weg, auf dem dieses Vertrauen still verschwindet. Flaky Tests frühzeitig zu erkennen und sie von Anfang an aus der Suite fernzuhalten, trennt eine nützliche QA-Funktion von einer lärmenden.

Wir haben über zwei Jahrzehnte damit verbracht, Test-Suites für SaaS, Fintech, E-Commerce, KI und Games in 300+ Projekten aufzubauen und zu retten. Wir haben chaotische, instabile Suites übernommen und sie wieder in etwas verwandelt, dem Teams wirklich vertrauen. Wenn Ihr Team mehr Zeit damit verbringt, Tests zu testen als sie zu schreiben, kontaktieren Sie uns oder erfahren Sie, wie ein dediziertes QA-Team das von Ihrem Teller nehmen kann.