7 Ways Selenium E2E Test Suites Fall Apart | Real Failures and Recovery Strategies from a QA Engineer

7 real-world failure stories from a QA engineer who ran Selenium E2E test automation into the ground — covering ChromeDriver version hell, Wait design chaos, xpath dependency, knowledge silos, and more. Learn the Selenium-specific patterns behind “tests that worked until they didn’t,” and the recovery strategies for each. Note: “technical debt” refers to the state where maintenance costs compound and grow like a snowball over time.

“It worked fine at first. Somehow, a year later, nobody could touch the code anymore.” — Selenium suite deterioration doesn’t happen suddenly. It creeps in, slowly.

“The first six months were smooth. But a year later, nobody touched the test code anymore.” — A scene I’ve watched repeat itself across multiple projects.

What these situations have in common is that the deterioration doesn’t hit all at once — it creeps in slowly. This article walks through 7 patterns of Selenium technical debt and the recovery strategy for each, based on direct experience.

7 Selenium Failure Patterns: Quick Reference

① What Is ChromeDriver Version Management Hell?

What happened

Monday morning: CI is down. The log says SessionNotCreatedException: This version of ChromeDriver only supports Chrome version XX. Chrome auto-updated over the weekend and the ChromeDriver version no longer matches.

“Just download the new ChromeDriver and swap it out.” Fine the first time. Then this happens every single week. Find the download page → check the version → replace the binary → re-run CI. Every Monday morning, eaten by this.

Early warning signs

• The ChromeDriver path is hardcoded in the test code
• No ChromeDriver version in requirements.txt
• CI environment Chrome version is managed as “roughly the latest”
• ChromeDriver download is a manual task

# ❌ Failure pattern: hardcoded ChromeDriver path
from selenium import webdriver
from selenium.webdriver.chrome.service import Service

driver = webdriver.Chrome(service=Service("/usr/local/bin/chromedriver"))
# Breaks every time the version doesn't match

# ✅ Option 1: Selenium Manager (built-in since Selenium 4.6+)
# Automatic ChromeDriver resolution is a standard feature from Selenium 4.6
# Note: CI/Docker environments may need extra setup due to OS dependencies
from selenium import webdriver
driver = webdriver.Chrome()
# No extra library needed (though environment-specific config may be required)

# ✅ Option 2: webdriver-manager (widely used in existing projects and CI)
from selenium import webdriver
from selenium.webdriver.chrome.service import Service
from webdriver_manager.chrome import ChromeDriverManager

driver = webdriver.Chrome(
    service=Service(ChromeDriverManager().install())
)
# Still valid for existing setups and Selenium < 4.6

② What Is the implicitWait / explicitWait Mix That Creates Flaky Hell?

※ Flaky tests are tests that pass sometimes and fail other times with no clear reason — they're unreliable and non-reproducible. When CI results vary from run to run, it becomes impossible to tell whether a failure is a real bug or just noise.

What happened

"Let's be thorough with waits." After reading the docs, I ended up with both implicitly_wait and WebDriverWait throughout the codebase. Result: tests that pass one day and fail the next — flaky tests with no reproducibility. "Did this failure mean a real bug?" became impossible to answer.

# ❌ Failure pattern: mixing implicitWait and explicitWait
driver.implicitly_wait(10)  # global setting

# elsewhere in the codebase
wait = WebDriverWait(driver, 5)
element = wait.until(EC.presence_of_element_located((By.ID, "submit")))
# timeout interference → unpredictable flakiness

# ✅ Recovery: unify on explicitWait
# Do NOT use implicitly_wait
# Use WebDriverWait for all waiting

from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.by import By

wait = WebDriverWait(driver, 10)
element = wait.until(
    EC.element_to_be_clickable((By.ID, "submit"))
)
element.click()

③ What Is the xpath Selector Dependency That Breaks on Every UI Refresh?

What happened

"As long as we can target the element, it's fine." Full-path xpath accumulated throughout the codebase. Six months later, a frontend redesign changed the HTML structure — and 280 of 300 tests failed simultaneously. All the xpath paths were now invalid.

# ❌ Failure pattern: full-path xpath dependency
driver.find_element(
    By.XPATH,
    "/html/body/div[2]/main/section[1]/form/div[3]/button"
)
# Any minor change to HTML structure causes total collapse

# ⚠️ Relative xpath can also be fragile
driver.find_element(By.XPATH, "//div[@class='btn-wrapper']/button[1]")
# Breaks if the class name changes

# ✅ Most stable: CSS Selector with data-testid
driver.find_element(By.CSS_SELECTOR, "[data-testid='submit-btn']")
# data-testid is a test-only attribute → establish a rule never to change it

# ✅ Second best: ID or name attribute
driver.find_element(By.ID, "submit-btn")
driver.find_element(By.NAME, "submit")

Selector stability comparison

④ What Is the 1,000-Line Script That Grew With No Design?

What happened

"Ship working tests first." Tests were added with that policy, until a single file exceeded 1,000 lines. Login logic was copy-pasted in 5 places — when the login screen's selector changed, all 5 needed updates. Missed patches started hiding bugs.

# ❌ Failure pattern: same logic scattered throughout the file
def test_purchase():
    driver.find_element(By.ID, "email").send_keys("user@example.com")
    driver.find_element(By.ID, "password").send_keys("pass")
    driver.find_element(By.ID, "login-btn").click()
    # ...purchase flow...

def test_profile():
    driver.find_element(By.ID, "email").send_keys("user@example.com")  # duplicate
    driver.find_element(By.ID, "password").send_keys("pass")           # duplicate
    driver.find_element(By.ID, "login-btn").click()                    # duplicate
    # ...profile flow...

# ✅ Recovery: consolidate with Page Object Model
class LoginPage:
    def __init__(self, driver):
        self.driver = driver

    def login(self, email: str, password: str):
        self.driver.find_element(By.ID, "email").send_keys(email)
        self.driver.find_element(By.ID, "password").send_keys(password)
        self.driver.find_element(By.ID, "login-btn").click()

# Test code only expresses intent
def test_purchase(driver):
    LoginPage(driver).login("user@example.com", "pass")
    # ...purchase flow only...

⑤ What Is the "Key Person Leaves and No One Can Touch the Code" Situation?

What happened

"Only person A understands these Selenium tests." Person A resigned. The month after, tests started failing with nobody able to fix them. No comments in the code. No environment setup documentation. "Tests fail, nobody fixes them" became the culture — and the automation became hollow.

Knowledge silo symptom checklist

※ Rather than just Yes/No, ask "what proportion of the team can handle this?" — one person being the only one who can do it is the essence of a knowledge silo.

⑥ What Is "Can't Run Headless — Can't Get Into CI"?

What happened

"Works locally" — but when pushed to the CI server (headless environment), errors everywhere. Investigation revealed test code scattered with operations that depended on browser window size and rendering behavior. Specifically, these problems were intertwined:

# ❌ Failure pattern: implementation that breaks in headless
# Scroll operation based on assumed screen size
driver.execute_script("window.scrollTo(0, 500)")
driver.find_element(By.ID, "submit").click()
# The element may not be at y=500 in headless

# ❌ Clicking a viewport-external element (fails in headless)
element = driver.find_element(By.ID, "footer-btn")
element.click()  # Error if off-screen

# ✅ Recovery option 1: scroll element into view, then interact
element = driver.find_element(By.ID, "submit")
driver.execute_script("arguments[0].scrollIntoView(true);", element)
element.click()

# ✅ Recovery option 2: set window size explicitly
from selenium import webdriver

options = webdriver.ChromeOptions()
options.add_argument("--headless")
options.add_argument("--window-size=1920,1080")  # fix size in CI
driver = webdriver.Chrome(options=options)

⑦ What Is the Selenium 4 Upgrade That Stopped All Tests Cold?

What happened

"There's a security patch — let's upgrade Selenium." After pip install selenium --upgrade took us from Selenium 3 to 4, the next morning's CI had over 150 of 200 tests failing simultaneously. Multiple deprecated APIs in Selenium 4, combined with no migration plan, caused the disaster.

Main API changes from Selenium 3 → 4

# ❌ Failure pattern: still using Selenium 3 deprecated APIs
driver.find_element_by_id("submit")          # removed in Selenium 4
driver.find_element_by_xpath("//button")     # removed in Selenium 4
driver.find_element_by_class_name("btn")     # removed in Selenium 4

# ✅ Selenium 4-compatible syntax (use By.XXX)
from selenium.webdriver.common.by import By

driver.find_element(By.ID, "submit")
driver.find_element(By.XPATH, "//button")
driver.find_element(By.CLASS_NAME, "btn")

When Is Keeping Selenium the Right Call?

This article has focused on operational problems, but migrating to Playwright is not the right answer for every team. The following cases are where staying with Selenium is the more realistic choice.

FAQ

Selenium is a proven tool with over 20 years of production history. Every pattern in this article reflects not a problem with Selenium, but the result of scaling without an operational design. Start checking the warning signs today. Address them one by one. A deteriorated setup can always be recovered.