Flaky tests are the single fastest way to destroy trust in a test suite. Once a test fails intermittently for reasons that have nothing to do with the code under test, engineers start ignoring red builds, re-running pipelines “just in case,” and eventually skipping the suite altogether under deadline pressure. In Selenium automation specifically, flakiness usually isn’t random; it’s the predictable result of a handful of well-known anti-patterns. Here’s how to find and fix them.
1. Stop Using Hard-Coded Sleeps
Thread.sleep() (or time.sleep() in Python) is the most common source of flakiness in Selenium suites, and also the easiest to fix. A fixed sleep either wastes time waiting longer than necessary, or worse, doesn’t wait long enough on a slow CI run, causing an intermittent failure that has nothing to do with your application logic.
Replace hard sleeps with explicit waits tied to actual conditions:
java
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement submitButton = wait.until(
ExpectedConditions.elementToBeClickable(By.id(“submit-btn”))
);
submitButton.click();
This waits only as long as needed and fails fast with a clear timeout message when something is actually wrong, rather than a vague assertion failure downstream.
2. Fix Synchronization Issues at the Source
Beyond simple waits, a large share of flakiness comes from race conditions between the browser and the test script: clicking an element before a page transition finishes, asserting on text before an API call resolves, or interacting with an element mid-animation. ExpectedConditions covers most of these cases (visibilityOf, elementToBeClickable, textToBePresentInElement, presenceOfElementLocated), but the underlying discipline matters more than the specific API: never assume the DOM is in the state you expect ,wait for a condition that proves it.
For animation-heavy UIs, waiting purely on visibility isn’t always enough, since an element can be visible but still mid-transition. In those cases, a short custom wait condition checking for a stable bounding box or a CSS transition-complete state is more reliable than padding a generic wait.
3. Handle Stale Element References Properly
StaleElementReferenceException shows up when the DOM re-renders after you’ve already located an element ,common in single-page apps with frequent re-renders. Rather than wrapping every interaction in a blanket try/catch, re-locate the element right before interacting with it, and use ExpectedConditions.refreshed() when polling for an element that may be replaced:
java
wait.until(ExpectedConditions.refreshed(
ExpectedConditions.elementToBeClickable(By.id(“submit-btn”))
));
If stale references are showing up constantly in a specific flow, it’s often a sign the app itself is re-rendering more than necessary ,worth flagging to the frontend team, not just working around in tests.
4. Use Resilient, Unique Locators
Brittle locators are a slower-burning but equally damaging source of flakiness. XPath expressions tied to DOM position (//div[3]/span[2]) break the moment a designer adds a wrapper div, producing failures that look like flakiness but are actually locator rot. Favor stable attributes ,ideally a dedicated data-testid,over CSS classes tied to styling or XPath tied to structure. Locators should describe what an element is, not where it happens to sit in the current markup.
5. Isolate Test State
Tests that depend on data or state left behind by a previous test are a classic source of intermittent failure, especially under parallel execution. A test that passes in isolation but fails when run alongside others is almost always a state leakage problem: shared test accounts, un-reset database state, or session/cookie bleed between test runs.
The fix is structural: each test should set up its own state and tear it down afterward, and test data should be scoped per-run (unique usernames, isolated database transactions, or containerized test environments) rather than shared across a suite. This matters more, not less, as you scale up parallel execution to speed up your pipeline.
6. Don’t Let Retries Hide Real Bugs
Retry logic (rerunning a failed test once or twice before marking it a true failure) is a reasonable pragmatic tool, but it’s frequently misused as a substitute for actually fixing flakiness. If a retry mechanism is quietly absorbing dozens of failures a week, that’s a signal, not a solved problem. Track retry rates per test as a metric, and treat any test that needs a retry to pass consistently as a bug in the test, not a quirk to tolerate indefinitely.
7. Account for Real Browser and Infrastructure Variance
Even a perfectly written test can flake for reasons outside the test code entirely: an overloaded Selenium Grid node, inconsistent browser versions across CI runners, network latency to a staging environment, or resource contention when too many sessions run in parallel on limited hardware. This is a common blind spot; teams debug their test code extensively while the actual instability is in the execution environment.
Signs this is your root cause: failures cluster around specific CI runners or times of day, failures disappear when run sequentially instead of in parallel, or failures correlate with grid/infrastructure load rather than any particular test. If that pattern shows up, the fix isn’t more waits or retries , it’s more stable, adequately resourced execution infrastructure, whether that’s scaling your own Selenium Grid properly or running against a managed, real-browser cloud grid built to handle parallel load without resource starvation.
8. Building a Flakiness Budget
Finally, treat flakiness as a metric you actively manage, not a background annoyance in Selenium automation testing. Track flaky test rates over time, quarantine chronically flaky tests instead of letting them erode confidence in the whole suite, and set a standard that a newly flaky test gets triaged within a sprint, not left to accumulate. Selenium automation testing suites that manage flakiness deliberately stay trustworthy; suites that don’t eventually get ignored entirely, which defeats the purpose of having automation in the first place.
