</>

Technology

Scenario-Based

Difficulty

Advanced

Interview Question

How do you maintain a large Selenium test suite and prevent test rot?

Answer

Maintaining Large Selenium Test Suites

Test suites rot when locators break, tests become flaky, and nobody refactors. Here is the maintenance discipline used in mature QA teams:

Rule 1 — Centralize All Locators in Page Objects

Java
// WRONG — locators scattered in test methods
@Test
public void loginTest() {
    driver.findElement(By.id("username")).sendKeys("admin"); // hardcoded
}

// RIGHT — all locators in Page Object
public class LoginPage {
    private By usernameField = By.id("username");  // change once, fixes all tests
    private By passwordField = By.id("password");
    private By loginBtn      = By.cssSelector(".btn-login");

    public LoginPage typeUsername(String user) {
        driver.findElement(usernameField).sendKeys(user);
        return this;
    }
}

Rule 2 — Track and Fix Flaky Tests Weekly

Java
// Tag flaky tests explicitly — don''t hide them
@Test(groups = {"flaky"})
@Issue("JIRA-456 — intermittent timeout on slow CI")
public void checkoutTest() { ... }

// Exclude flaky from main pipeline
// Fix by end of sprint — otherwise delete the test

Rule 3 — Strict Naming Conventions

Java
// Method name pattern: should{ExpectedBehavior}When{Condition}
public void shouldShowErrorWhenPasswordIsMissing() { }
public void shouldRedirectToDashboardAfterValidLogin() { }
public void shouldDisplayTotalPriceIncludingTax() { }

// Easy to understand failures without reading code

Rule 4 — Page Object Review on UI Changes

When dev pushes a UI change:

  1. Run smoke suite — identify broken tests
  2. Update locators in Page Object only (not in 50 test methods)
  3. Re-run to verify fix
  4. Merge Page Object update

Rule 5 — Monthly Refactoring Sprint

CODE
Week 1-3: Feature/test development
Week 4:   Maintenance week
  - Fix all flaky tests (or delete them)
  - Update deprecated locators
  - Remove obsolete tests (feature removed)
  - Add missing test coverage
  - Review test execution time trends

Rule 6 — Code Review for Test PRs

Every new test must be reviewed for:

  • No hardcoded waits (Thread.sleep)
  • No hardcoded locators outside Page Object
  • Test is independent (no dependency on other tests)
  • Meaningful assertion messages
  • Clean setup and teardown

Rule 7 — Deletion Policy for Dead Tests

Java
// Test has failed 5+ consecutive runs
// No one has fixed it in 2 sprints
// → DELETE the test, file bug separately

// Keeping broken tests is worse than no test
// They add noise and reduce trust in the suite

Maintenance Metrics to Track

CODE
Flakiness rate:     Target < 2%  — Alert if > 5%
Pass rate trend:    Alert if drops > 3% week-over-week
Test count growth:  +5-10 new tests per sprint
Execution time:     Alert if suite grows > 30 min
Disabled tests:     Review all @Test(enabled=false) monthly

Follow AutomateQA

Related Topics