Selenium · Browser automation foundations

How do you diagnose and fix flaky Selenium tests?

Hardflaky testsdebuggingstabilityUpdated Oct 2026

Short answer

Treat flakiness as a defect with a cause. Reproduce it, inspect logs and traces, and fix the specific race, shared state, unstable locator or environment issue rather than adding sleeps or retries.

Flakiness usually comes from a small set of causes: waiting for the wrong state, shared data, order dependence, animation, unstable locators, network variability, or resource exhaustion. The fix depends on the cause, so the first job is evidence, not another wait.

java

Thread.sleep(5000);
driver.findElement(By.cssSelector(".btn-primary")).click();

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement save = wait.until(ExpectedConditions.elementToBeClickable(
    By.cssSelector("[data-testid='save']")));
save.click();
wait.until(ExpectedConditions.textToBePresentInElementLocated(
    By.cssSelector("[role='status']"), "Saved"));

Replace a guessed delay and a brittle selector with a state-based wait and a stable locator.

Capture the URL, title, screenshot, console logs and driver logs on failure
Check whether the test fails alone, in a group, or only in parallel
Look for shared users, fixed file paths, shared database rows and order dependence
Wait for the specific post-action state instead of a generic page load
Replace generated classes and positional selectors with stable test ids
Watch for animations and overlays that intercept clicks
Measure flake rate per test rather than relying on anecdotes

Quarantine a persistently flaky test so it stops blocking the pipeline, but keep it running in a non-blocking job and give it an owner. Deleting the test hides the coverage gap; leaving it in the blocking suite erodes trust in every red build.

A retry that makes a flaky test green is not a fix. It is a delay that makes the next investigation harder because the failure evidence is no longer produced.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

1What evidence do you collect for a flaky failure?
2How do you tell a product race from a test race?
3When would you quarantine a test?
4Why can a test pass alone but fail in a suite?

Say it in the interview

I start from evidence: screenshot, URL, console and driver logs, and whether the failure reproduces alone or in parallel. Then I map it to a cause such as a wrong wait condition, shared data, an unstable locator or an overlay. I fix that cause instead of adding a sleep or a retry. Persistently flaky tests get quarantined with an owner so they stop blocking the pipeline without losing the coverage.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Selenium mock interview and get scored feedback on depth, clarity and confidence.

Start a free Selenium interview Browse all questions

Follow-ups you should expect

Related questions

Now say it out loud.