How to Find and Fix Flaky Selenium Tests

What Are Flaky Selenium Tests

A flaky Selenium test passes or fails on the same code with no change to the build. It defeats automation because a red build no longer reliably signals a real bug in the application under test (AUT).

Determinism is the property that lets a test detect bugs: it gives the same result whenever the code has not changed.

A flaky test breaks that rule. It passes once, fails the next time, then passes again. That inconsistency defeats the purpose of automation testing.

Flakiness is not a nuisance you can ignore. It hurts in four concrete ways:

• Erodes trust - engineers start ignoring failures and dismiss real defects as "just flakiness."
• Drains time - reruns and false positives consume effort that could go to real work.
• Carries hidden cost - creation, fixing, execution, and debugging all add up around a flaky suite.
• Grows over time - an unmaintained suite gets flakier, and teams retreat to slow manual testing.

What Causes Flaky Selenium Tests

Selenium itself is deterministic. Flakiness comes from the test and its surroundings: timing, unstable locators, shared test data, the environment, parallelism, weak assertions, and poor test logic.

The Selenium WebDriver bindings are a thin wrapper over a deterministic protocol, standardized by the Selenium 4 W3C WebDriver protocol. So the randomness enters elsewhere.

The seven usual sources break down like this:

How Do You Detect Flaky Tests

Detect flaky tests by running the suite repeatedly in CI and watching which tests fail intermittently. Failure-frequency analysis ranks tests by how often they fail, so the chronic offenders surface first.

Common Errors

These exceptions are the usual signature of a flaky failure. Each points at a specific cause:

Each exception traces back to a cause from the previous section, so the fix is almost always better synchronization in Selenium WebDriver or a more stable locator.

Rerun and Track

A single red run tells you nothing. Rerun the suite many times in CI, ideally daily, and record which tests fail without a code change.

Doing this by hand does not scale. TestMu AI's Test Intelligence surfaces flakiness through failure-frequency analysis, ranking tests by how often they fail across the whole history.

That lets you fix the worst offenders first. Its AI triage then labels each failure as app logic, network, device state, or test script, so you know whether the cause is the test or the environment.

Treat that output as a strong lead to verify, not a final verdict.

How Do You Fix Flaky Selenium Tests

Fix flaky Selenium tests at the root cause: replace sleeps with explicit waits, swap brittle XPath for stable locators, isolate test data, and quarantine the rest while you fix them.

Work one test at a time so you find the true root cause and ship a permanent fix. The examples below run against the Selenium Playground.

Synchronize With Explicit Waits

Replace fixed Thread.sleep calls with an explicit wait that blocks until a specific condition is true. Use Selenium waits over hard-coded pauses.

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(15));

driver.get("https://www.testmuai.com/selenium-playground/simple-form-demo");
driver.findElement(By.id("user-message")).sendKeys("Stable Selenium test");
driver.findElement(By.id("showInput")).click();

// Block until the result actually renders, then read it
WebElement output = wait.until(ExpectedConditions
    .textToBePresentInElementLocated(By.id("message"), "Stable Selenium test"));

We ran this exact flow on the TestMu AI cloud against the Simple Form Demo. The wait holds until the message renders, then the assertion passes deterministically.

Handling stale element exceptions in Selenium works the same way: after an AJAX update, re-locate the element through the wait instead of reusing a cached one:

// Bad: the cached reference goes stale when the DOM re-renders
WebElement el = driver.findElement(By.id("submit"));
el.click(); // StaleElementReferenceException

// Good: re-locate through the wait every time
wait.until(ExpectedConditions.elementToBeClickable(By.id("submit"))).click();

Use Reliable Locators

Prefer a dedicated test attribute, then a stable ID, then a short relative XPath. Reach for an absolute path only when nothing else exists.

// Best: a dedicated test hook the UI framework will not rename
driver.findElement(By.cssSelector("[data-testid='email']"));

// Good: a stable id
driver.findElement(By.id("user-message"));

// Acceptable: a short relative XPath anchored to a stable attribute
driver.findElement(By.xpath("//input[@name='email']"));

Keep one locator per element in a Page Object so a UI change is a one-line fix. For stable patterns, keep our XPath locators cheat sheet and guide to CSS selectors handy.

Isolate Test Data

Give each test the data it needs and tear it down afterward. Generate unique users or records per run instead of sharing a fixed account.

This is what lets a suite survive parallel execution without one test corrupting another. Isolation removes the whole class of shared-state flakiness.

Add Retry Logic

Retry is a stopgap while you fix the root cause. Use IRetryAnalyzer in TestNG to reattempt a failed test a fixed number of times:

public class RetryAnalyzer implements IRetryAnalyzer {
    private int count = 0;
    private static final int MAX_RETRY = 2;

    @Override
    public boolean retry(ITestResult result) {
        return count++ < MAX_RETRY; // retry a failed test up to twice
    }
}

// Attach it to a known-flaky test while you work on the real fix
@Test(retryAnalyzer = RetryAnalyzer.class)
public void checkoutFlow() { /* ... */ }

Retry hides intermittent failures, so it buys time but never fixes the cause. Pair it with tracking and remove it once the test is stable.

Quarantine Flaky Tests

Move a known-flaky test out of the blocking suite into a separate quarantine group. The gate stays trustworthy while you investigate.

Keep running the quarantine group so it stays visible, and set a rule that tests do not linger there. Quarantine is a holding cell, not a graveyard.