Selenium Automation Checklist: 10 Things to Check Before Every Test Run

Nothing frustrates a QA Automation team more than false-negative build failures in Jenkins or GitHub Actions. You trigger a 200-test regression suite overnight, only to wake up to 45 failed tests caused not by application bugs, but by StaleElementReferenceException, hardcoded Thread.sleep() timeouts, or browser binary mismatches.

Rule 1: Eliminate Hardcoded Thread.sleep() and Use Explicit Waits

Hardcoding Thread.sleep(5000) is the #1 cause of slow and flaky test suites. It forces execution to pause regardless of whether the DOM element loaded in 100 milliseconds or 4 seconds. Always utilize WebDriverWait with ExpectedConditions.

Rule 2: Never Mix Implicit and Explicit Waits

Combining driver.manage().timeouts().implicitlyWait() with explicit WebDriverWait produces unpredictable wait timeouts in Selenium. When both are active, total wait times can double or throw immediate timeout exceptions. Choose Explicit Waits universally across your Page Object Model framework.

Rule 3: Use WebDriverManager or Selenium 4 Manager for Automatic Driver Binaries

Manually downloading chromedriver.exe or geckodriver.exe into project folders breaks build pipelines whenever Chrome auto-updates. Selenium 4 built-in Selenium Manager or Boni Garcia's WebDriverManager automatically handles driver binary version alignment.

Rule 4: Implement Dynamic Custom Locators (Avoid Absolute XPaths)

Absolute XPaths like /html/body/div[2]/div[1]/form/input[3] break with any minor UI layout tweak. Utilize robust relative locators leveraging data attributes (e.g., [data-testid="login-btn"]) or stable CSS selectors.

Rule 5: Always Clean Up Driver Sessions in @AfterMethod / @AfterClass

Rule 6: Handle Dynamic iFrames & Window Handles Cleanly

Before interacting with embedded payment gateways or popups, verify frame switching logic. Always switch back to default content after completing iframe operations: driver.switchTo().defaultContent().

Rule 7: Configure Headless Mode and Screen Resolution for CI/CD Builds

In headless Linux build servers (Docker / Jenkins), elements may render differently due to small default viewport dimensions. Explicitly set window dimensions: options.addArguments("--window-size=1920,1080").

Rule 8: Capture Automatic Screenshots on Test Failure

Configure TestNG ITestListener or JUnit 5 Extension to automatically capture full-page screenshots and attach them to Allure or ExtentReports upon test failure.

Rule 9: Isolate Test Data & Avoid Inter-Test Dependencies

Each test method should be atomic and independent. Test A should never rely on state created by Test B. Use random UUIDs or DB seed scripts for fresh test data execution.

Rule 10: Validate API State Before Running Heavy UI Automation

Pre-populate prerequisites via fast REST API calls (e.g., creating a test user account or adding items to cart via API) before executing web UI assertions. This cuts suite execution time by 60%!

Frequently Asked Questions (FAQ)

Summary Table: The 10-Point Pre-Flight Checklist

Bonus: Common Selenium Exceptions & Their Causes

Beyond pre-flight checks, understanding why specific exceptions occur helps you write more resilient automation code. Here are the top 5 Selenium exceptions every SDET must master:

• StaleElementReferenceException — DOM refreshed after element was located. Re-locate element inside retry loop.
• NoSuchElementException — Locator incorrect or element not yet rendered. Switch to Explicit Wait.
• ElementNotInteractableException — Element is hidden, overlapped, or disabled. Use JavaScript executor to interact.
• TimeoutException — Wait condition not met within timeout period. Increase wait duration or fix locator.
• WebDriverException: Chrome not reachable — ChromeDriver binary version mismatch with Chrome browser. Update WebDriverManager.

Advanced: Selenium Page Object Model (POM) Template

Selenium 4 vs Selenium 3: Key Differences Every SDET Must Know

Selenium 4 introduced major architectural improvements including native W3C WebDriver protocol compliance, Chrome DevTools Protocol (CDP) integration, relative locators, and built-in grid 4 with Docker support. If you are still using Selenium 3, upgrade to unlock these features.

Setting Up Selenium with TestNG and Maven: Complete pom.xml

Setting Up Selenium Grid 4 with Docker for Distributed Testing

Selenium Grid 4 enables running tests across multiple browsers and machines simultaneously. Unlike Selenium Grid 3 which required complex hub-node configuration, Grid 4 introduces a fully distributed architecture with auto-registration, built-in observability via OpenTelemetry, and native Docker Compose support.

A Docker-based Selenium Grid 4 setup brings up a Hub (Router + Distributor + Session Map) and N browser nodes with a single docker-compose up command. This is the recommended approach for CI/CD environments where you want reproducible, isolated browser environments without manual ChromeDriver management.

Cross-Browser Testing Strategy: Chrome, Firefox, Edge, and Safari

A robust Selenium automation framework must validate critical user journeys across multiple browsers. Browser rendering differences cause real production bugs — CSS flex behavior varies between browsers, JavaScript ES2022 features may not be supported on older Safari versions, and form autofill behavior differs significantly.

Implement a BrowserFactory pattern that creates the appropriate WebDriver instance based on a system property passed from Maven or CI/CD. This allows running the same test suite against Chrome, Firefox, and Edge without any code changes:

TestNG Listeners: Custom Reporting and Failure Screenshots

TestNG Listeners intercept test lifecycle events (onTestFailure, onTestSuccess, onTestStart) and allow custom actions without modifying individual test methods. The most important listener for production frameworks is the ITestListener implementation that captures screenshots automatically on every test failure.

Debugging Flaky Selenium Tests — Root Cause Analysis Framework

Flaky tests — tests that pass sometimes and fail other times without code changes — are the #1 productivity killer for automation teams. A systematic root cause analysis framework helps you categorize and fix flakiness efficiently rather than just adding more wait time.

• Category 1 — Timing Issues (60% of flakiness): Element not yet rendered when interaction attempted. Fix: Replace ALL implicit waits with explicit WebDriverWait + ExpectedConditions.
• Category 2 — Test Data Conflicts (20%): Parallel tests share the same user account and conflict. Fix: Create unique test users per test method using UUID-suffixed email addresses.
• Category 3 — Stale Element References (10%): DOM re-renders (React/Angular) after element location. Fix: Encapsulate element interactions in a retry wrapper with StaleElementReferenceException catch.
• Category 4 — Environment Issues (10%): Test environment performance degrades during heavy load. Fix: Reduce parallel thread count on CI runners, add environment health check before test run.

Advanced: Selenium CDP (Chrome DevTools Protocol) Integration

Selenium 4 natively integrates Chrome DevTools Protocol (CDP), unlocking powerful capabilities previously impossible with WebDriver alone: network request interception, console log capture, geolocation spoofing, and mock HTTP responses. This enables a new category of end-to-end tests that validate application behavior under simulated conditions.

Selenium Best Practices for Large-Scale Enterprise Frameworks

Building a Selenium framework used by 20+ QA engineers simultaneously requires architectural decisions beyond basic WebDriver usage. Here are the patterns adopted by enterprise automation teams:

• ThreadLocal WebDriver: Use ThreadLocal<WebDriver> in BaseTest to ensure each parallel test thread gets its own isolated browser instance, preventing shared-state conflicts.
• Fluent Page Objects: Return this or the next page object from every action method to enable fluent chaining: loginPage.enterEmail().enterPassword().clickLogin().
• Element Wait Abstraction: Create a WaitHelper utility class wrapping all WebDriverWait patterns. Never call new WebDriverWait() in test or page classes — only in the utility layer.
• Configuration via Properties Files: Never hardcode URLs, credentials, or timeouts. Load them from environment-specific .properties files using a ConfigReader singleton.
• Test Data via Faker Libraries: Use Java Faker library to generate realistic test data (names, addresses, credit cards) rather than static constants that accumulate in databases.

Selenium & Playwright Comparison — 2026 Decision Guide

References & Official Documentation

• Selenium Official Documentation — WebDriver API, Grid 4, and BiDi protocol.
• WebDriverManager GitHub — Automatic browser driver management library.
• TestNG Documentation — Parallel execution, listeners, and DataProvider patterns.
• Allure Report Framework — Test reporting with step-by-step evidence and screenshots.