Selenium · Browser automation foundations

Should you retry failed Selenium tests automatically?

Mediumretriesflaky teststestngUpdated Oct 2026
Quiz this track

Short answer

Retry sparingly as a temporary safety net, not as a substitute for fixing flakiness. One or two retries can protect a release from known infrastructure noise, but every retry must be logged and investigated.

A retry hides a failure on the first attempt. That is acceptable when the cause is a known transient such as a Grid node restart, but dangerous when it masks a real race in the product or the test. The default should be to fix the cause.

java
public class RetryAnalyzer implements IRetryAnalyzer {
    private int attempts = 0;
    private static final int MAX_ATTEMPTS = 1;

    @Override
    public boolean retry(ITestResult result) {
        if (attempts < MAX_ATTEMPTS) {
            attempts++;
            return true;
        }
        return false;
    }
}

@Test(retryAnalyzer = RetryAnalyzer.class)
public void checkoutWorks() {
    new CheckoutPage(driver()).completeOrder();
}
A small retry budget, applied deliberately rather than to the whole suite.
  • Retry the smallest scope possible, ideally a known flaky test rather than every test
  • Keep the retry count low; repeated retries multiply runtime and hide systemic issues
  • Record that a test passed on retry and report it separately from a clean pass
  • Quarantine tests that need constant retries and assign an owner
  • Do not retry assertion failures that indicate deterministic product bugs
  • Ensure retries do not leak data or duplicate side effects

A retry analyzer may be instantiated or reused in ways that make a simple counter unsafe under parallelism. Verify the runner's behaviour or use a thread-safe implementation. The retry decision should be visible in the report so nobody mistakes a retried pass for a healthy test.

Retries are a diagnostic signal. If the retry rate rises, the suite is getting less trustworthy even if the pipeline stays green.

Follow-ups you should expect

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

  1. 1When is an automatic retry justified?
  2. 2Why is a retry counter unsafe under parallelism?
  3. 3How do you report a test that passed on retry?
  4. 4What would make you remove retries entirely?

Say it in the interview

I treat retries as a temporary safety net for known infrastructure noise, not as a fix for flaky tests. I scope them to specific tests, keep the count low and report retried passes separately so they are visible. Deterministic assertion failures should never be retried. If the retry rate grows, I stop adding retries and investigate the root cause.

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

Related questions

Reading is step one

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.