How to fix a flaky test suite for good
A flaky test passes and fails without any code change. A few of them and your team stops trusting the whole suite. The fix is rarely one big thing, it is a handful of habits. Here they are.
By Quality AboveAll · May 3, 2026 · 7 min read
Where this fits in the wider picture.
How to fix a flaky test suite for good
We work inside your team
Your standups, your repos, your release calls.
Numbers you can audit
Every claim backed by a metric you can check.
Green builds, always
CI/CD that blocks the merge instead of the release.
Built for the traffic you expect next
Capacity modelled against real growth curves.
Ready for the audit
Traceable artefacts for regulated environments.
Flaky tests pass and fail without a code change, and they destroy trust in your suite. Fix them by removing fixed waits, isolating test data, stabilizing selectors, and quarantining, then repairing. Modern tools like Playwright prevent most of it.
Why flakiness is so expensive
A flaky suite is worse than no suite. When red can mean nothing, people stop trusting green, and they start ignoring real failures. The whole safety net stops working.
The usual causes, and the fixes
- Fixed waits. Replace
sleep(3)with proper waits. Playwright auto-waits for elements, which removes a whole class of flakiness that older Selenium suites suffer from. - Shared test data. Tests that depend on each other's data fail at random. Isolate state per test.
- Brittle selectors. Target stable roles and test IDs, not fragile CSS paths.
- Order dependence. Every test should pass on its own, in any order.
- Real network calls. Mock third parties so an outage elsewhere does not redden your build.
A process that keeps it fixed
Quarantine flaky tests out of the blocking suite so they stop crying wolf, then fix them on a clock, not someday. Track your flaky rate as a number. What gets measured gets fixed. This is core to our automation framework and modernization work, gated in CI/CD.
A smaller suite you trust beats a bigger one you do not.
If your team is re-running builds to get them green, that is flakiness, and it is fixable. Start with a testing audit.
Questions about this topic.
What causes flaky tests?
Mostly timing assumptions, shared state between tests, and dependence on real external services. Fixed sleeps and tests that must run in a particular order account for a large share of what teams see.
Should we delete flaky tests?
Quarantine first, delete only after investigation. A flaky test sometimes signals a genuine race condition in the product, and deleting it removes the evidence along with the noise.
How do you stop flakiness coming back?
Track flake rate as a metric, fail the build on newly flaky tests, and fix by root cause rather than by adding retries, which hide the underlying timing problem and slow the suite.
How ready is your product to ship and scale?
Answer 12 questions and get a maturity score across architecture, delivery, quality and security, plus the three things we would fix first. No email required to see your result.
Senior-led QA,embedded in your workflow.
Often less than one full-time hire. Book a free 30-minute testing audit and we'll show you exactly where the risk is hiding.