Red builds with no code changes
Recurring failures even after identical code. Usually caused by timing, data, or environment factors.
Flaky, not faultyFlakiness field guide
How to Fix Flaky Tests: Causes, Fixes, and Prevention
Flaky tests pass one run and fail the next without product changes. This guide covers causes, fixes, and how QAlity Auto-Heal and cloud execution help QA teams keep browser suites stable.
Flake isolated
Signal recovering
Real signals. Real impact.
What it looks like
on your team
These signals usually mean timing or locator instability, not a broken product.
Element not found / stale element
WebDriver loses the element reference due to DOM re-render or a moving target.
Locator instability
Timeouts only under load
Tests pass locally but fail in CI or under parallel execution due to performance or timing.
Performance & timing
Ignored or quarantined tests
Tests are often skipped or isolated instead of fixed, hiding real quality risks.
Quality visibility gap
Identify. Understand. Fix.
Root causes
Common sources of flaky, slow, or unstable tests that impact reliability and developer productivity.
-
Race conditions and poor waits
Fixed sleeps hide timing issues until load or network latency changes. Waiting for visible, clickable, or stable state beats arbitrary delays.
-
Brittle locators
XPath tied to layout, auto-generated IDs, and deep DOM paths break when designers refactor. Prefer stable roles, labels, and test hooks.
-
Environment and data drift
Different browsers, resolutions, time zones, or shared accounts cause tests to step on each other in shared CI grids.
-
Framework and driver overhead
Selenium WebDriver adds layers between your test and the browser. Small timing gaps in driver, grid, or app startup compound under heavy CI load.
BEST PRACTICES
BEST PRACTICES
What to do
Stability is a design choice. Follow these proven practices to build reliable, maintainable, and scalable test automation.
-
Wait for conditions, not clocks
Avoid fixed sleeps. Wait for real conditions to make tests faster and more reliable.
- Use explicit waits for elements, network idle, or API responses
- Use smart waits for visibility, clickability, and data readiness
- Remove Thread.sleep-style delays from happy paths
-
Isolate data and accounts
Keep tests independent by isolating data, users, and environments.
- Give each CI worker unique users, carts, or records
- Avoid shared data and dependencies between tests
- Ensure order-independent test execution
-
Track and burn down flake rate
Measure flakiness to improve stability and build team confidence.
- Tag flaky failures and retry only in investigation mode
- Analyze trends and fix root causes permanently
- Track flake rate as a quality KPI
-
Reduce locator maintenance
Make selectors resilient and reduce the effort needed to maintain tests.
- Use stable attributes and data-test selectors
- Implement self-healing or recorder-based tools
- Update selectors in one place with reusable patterns
Built for flaky. Fixed by QAlity.
How QAlity solves flaky Selenium tests
Intelligent self-healing, environment parity, and cloud execution—so your tests stay reliable, everywhere.
- Self-Healing Automation
- Environment Parity
- Faster, Reliable Test Runs
The problem
Element not found and stale-element errors when the DOM re-renders
How QAlity fixes it
Auto-Heal recovers the step instead of failing the run
When WebDriver loses an element between find and click, Auto-Heal uses AI to find the current match in the live DOM and updates the XPath or selector so the run continues—without another round of script edits and reruns.
How Auto-Heal worksThe problem
Passes locally, fails in CI—or the opposite, with no way to tell which environment lied
How QAlity fixes it
Cloud execution removes machine-to-machine variance
Run the same suite on the same cloud agents every time. That separates true product regressions from laptop timing, browser extensions, and ad hoc CI images—so flake triage starts with comparable runs, not guesswork.
Cloud executionRelated reading
Connect this guide to the bigger picture.
Keep exploring related problem guides and platform comparisons for the same quality challenges.
More problem guides
Platform comparisons
Questions, answered
What teams ask before they start
Quick answers to the most common questions teams have before getting started with QAlity.
What are flaky tests?
Flaky tests are automated checks that produce inconsistent results, passing locally and failing in CI, or failing intermittently on the same build without code changes.
Why do browser tests become flaky?
Browser tests flake because of race conditions, brittle locators, shared test data, animation timing, and differences between local machines and CI agents.
How can QA teams reduce flaky tests?
Use explicit waits on stable conditions, isolate test data, track flake rate, and reduce locator maintenance with resilient selectors or Auto-Heal during runs.
Can no-code automation reduce flaky tests?
Yes. Platforms that record real browser interactions and heal broken selectors reduce manual locator upkeep, a major source of intermittent UI failures.
How does QAlity help with flaky UI tests?
QAlity Auto-Heal recovers broken locators during execution and execution history shows step-level screenshots so teams fix real regressions faster.
Should flaky tests be deleted or fixed?
Fix root causes when possible. Delete or quarantine tests only after investigation proves they add no signal, otherwise coverage shrinks while risk grows.
Is Selenium the only source of flaky tests?
No. Any browser automation can flake, but Selenium WebDriver stacks often see more timing and locator issues due to framework layers and manual script maintenance.
Stabilize tests without more scripts
Start free - record a flow, run it in the cloud, and see Auto-Heal in action.