Selenium Interview Questions and Answers

Selenium interviews test whether you can automate browsers reliably and design maintainable frameworks—not only call click().

Automate stable, high-value paths—login, checkout, critical CRUD—not every edge case. Keep exploratory testing manual.

Experienced SDET loops weight framework design and Java integration heavily—POM boundaries, explicit waits, and parallel-safe drivers matter as much as locator trivia.

Use a public demo site (e.g. Sauce Demo, automation practice pages) or your own staging environment—never production credentials in samples.

Selenium remains the default where Java + TestNG + Grid investments already exist. Playwright wins many new SDET projects for resilience and speed—but interviewers want you to articulate trade-offs, not dismiss Selenium.

WebDriver speaks to each browser through a driver binary (chromedriver, geckodriver, etc.). Your test code never drives the browser directly—it sends W3C WebDriver commands over HTTP.

A strong answer is:

Production work is WebDriver plus Grid when we need parallel browsers; IDE is for spikes, and RC is historical only—I wouldn't build new frameworks on it.

Flow:

Test script (Java + bindings)
        ↓
JSON HTTP (W3C WebDriver commands)
        ↓
Browser driver (ChromeDriver, GeckoDriver, …)
        ↓
Real browser (Chrome, Firefox, Edge, Safari)

1. Your language bindings serialize calls like driver.findElement(By.id("login")) into HTTP requests.
2. The driver translates them into browser-specific automation.
3. The browser executes DOM actions and returns element references or errors.

This separation lets one Java API target multiple browsers—swap the driver executable, keep test logic.

A strong answer is:

My Java test talks to a driver over W3C HTTP; the driver controls the real browser—so version alignment between browser and driver is an ops concern I plan for in CI.

Selenium 4 standardized on the W3C WebDriver protocol instead of the legacy JSON Wire Protocol.

Interviewers use this to check whether you understand why Selenium 4 reduced some cross-browser quirks—not just the version number.

A strong answer is:

Selenium 4's W3C alignment means drivers speak a standard protocol directly—fewer translation bugs—and unlocks relative locators and cleaner multi-window handling I'd use in new code.

A driver is a separate executable that exposes WebDriver endpoints. Selenium Manager (Selenium 4.6+) can auto-download matching drivers in many setups—still verify in CI.

Mismatch symptom:

SessionNotCreatedException: session not created: This version of ChromeDriver only supports Chrome version 120

A strong answer is:

I pair each browser with its driver and pin versions in CI—Selenium Manager helps locally, but pipelines need explicit alignment to avoid SessionNotCreated failures.

ChromeOptions options = new ChromeOptions();
options.addArguments("--headless=new");
WebDriver driver = new ChromeDriver(options);

Use headless in CI for speed; switch to headed locally when debugging locators or timing. Some teams run headed smoke on a schedule for visual confidence.

A strong answer is:

CI runs headless for speed; when a test fails I reproduce headed locally—or capture screenshot/video—because some rendering and focus bugs never show headless.

Relative locators find elements near other elements—useful when IDs are missing but layout is stable.

import static org.openqa.selenium.support.locators.RelativeLocator.with;

WebElement password = driver.findElement(with(By.tagName("input"))
    .below(driver.findElement(By.id("username"))));

Prefer id / data-testid / CSS first; use relative locators when the DOM has no stable attributes but spatial layout is consistent.

A strong answer is:

Relative locators are my fallback when there's no id or data-testid—I anchor on a labeled field and find the input below it, knowing layout changes break these faster than semantic selectors.

Built-in strategies: id, name, className, tagName, linkText, partialLinkText, cssSelector, xpath.

Recommended priority (most stable → least):

1. id or data-testid (if your app adds test hooks)
2. name (when unique)
3. CSS selector — fast, readable
4. XPath — powerful for text/axes; slower and brittle if overused

The simulation below scores locators the way many style guides rank stability (lower score = prefer first):

import java.util.*;

public class LocatorPriority {
    static int score(String strategy) {
        return switch (strategy) {
            case "id", "data-testid" -> 1;
            case "name" -> 2;
            case "css" -> 3;
            case "xpath" -> 4;
            default -> 5;
        };
    }

    public static void main(String[] args) {
        List<String> strategies = List.of("xpath", "id", "css", "data-testid");
        strategies.stream()
            .sorted(Comparator.comparingInt(LocatorPriority::score))
            .forEach(System.out::println);
    }
}

When you run this, stdout lists strategies from most to least preferred: id, data-testid, css, then xpath.

A strong answer is:

I start with id or data-testid, then CSS; XPath only when I need text or axis navigation—and I push devs to add test IDs so I don't rely on fragile full XPath paths.

// CSS
driver.findElement(By.cssSelector("input[data-testid='email']"));

// XPath — useful for button text
driver.findElement(By.xpath("//button[normalize-space()='Sign in']"));

Avoid absolute XPath from /html/body/...—any DOM insert breaks it.

A strong answer is:

CSS for attributes and structure; XPath when I must target visible text or traverse siblings—never a full absolute path from html root.

Use findElements when checking optional UI (cookie banner, promo modal) or counting matches. Use findElement when the element must exist—fail fast with a clear exception.

A strong answer is:

findElement when absence should fail the test; findElements when I'm probing optional UI or verifying zero results without catching exceptions.

A stale element occurs when the DOM node you held was removed or replaced (AJAX refresh, React re-render) between findElement and click().

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement btn = wait.until(ExpectedConditions.elementToBeClickable(By.id("submit")));
btn.click();

ExpectedConditions returns a fresh element reference after the wait condition passes—preferred over storing WebElement in fields across long flows.

A strong answer is:

Stale means the DOM node died—I re-locate inside WebDriverWait instead of caching WebElement across AJAX or React updates, and I avoid combining stale-prone caches with parallel runs.

Actions chains low-level input events that simple click() cannot express:

Actions actions = new Actions(driver);
actions.moveToElement(menu).click(subItem).perform();

Always call perform() to execute the chain. Combine with explicit waits so elements are visible before hovering.

A strong answer is:

Actions handles hover, drag-drop, and chord keys—I'd still wait for visibility first, then perform the chain once, instead of sprinkling sleep between moves.

JavascriptExecutor runs JavaScript in the browser context—escape hatch when WebDriver API is insufficient.

JavascriptExecutor js = (JavascriptExecutor) driver;
js.executeScript("arguments[0].scrollIntoView(true);", element);

If you always JS-click because elements aren't clickable, fix timing or UI—not the test hack.

A strong answer is:

JavaScriptExecutor for scroll-into-view or rare DOM quirks—not as a default click replacement; if I need it everywhere, the app or my waits are wrong.

// Implicit — set once (use sparingly)
driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(5));

// Explicit — preferred per action
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(15));
wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("dashboard")));

Explicit waits target the exact condition (clickable, invisible loader gone)—best control for flaky SPAs.

A strong answer is:

I rely on explicit WebDriverWait for each interaction point; implicit wait is at most a small global safety net—and I never stack both aggressively on the same flow.

Both mechanisms poll the driver. Combined, total wait time can become implicit + explicit (or worse, unpredictable) because implicit wait applies inside explicit wait's internal lookups.

driver.manage().timeouts().implicitlyWait(Duration.ZERO);
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(20));

A strong answer is:

I set implicit to zero in serious frameworks and use explicit conditions only—mixing both inflated wait times in a suite I debugged and made runs painfully slow.

Alerts (JS dialogs):

Alert alert = driver.switchTo().alert();
alert.accept(); // or dismiss(), getText()

Frames / iframes:

driver.switchTo().frame("payment-frame");
// interact inside frame
driver.switchTo().defaultContent();

Windows / tabs:

String main = driver.getWindowHandle();
for (String handle : driver.getWindowHandles()) {
    if (!handle.equals(main)) {
        driver.switchTo().window(handle);
        break;
    }
}

Always return to default content or main window before the next step to avoid context leaks.

A strong answer is:

I switch context deliberately—frame for embedded payment, window for popup—then always switch back to defaultContent or the main handle so the next step isn't operating in the wrong context.

PageLoadStrategy controls how soon driver.get(url) returns:

ChromeOptions options = new ChromeOptions();
options.setPageLoadStrategy(PageLoadStrategy.EAGER);

Useful for SPAs where document.ready fires before your app renders—pair with explicit wait on a known element, not blind speed.

A strong answer is:

eager or none plus explicit wait on a app-specific element beats normal page load on heavy SPAs that block on analytics—I still wait for the UI I care about, not every asset.

Select country = new Select(driver.findElement(By.id("country")));
country.selectByVisibleText("India");

driver.findElement(By.id("file")).sendKeys("/path/to/document.pdf");

Hidden file inputs still accept sendKeys when the input exists in DOM—no need to open the OS dialog.

A strong answer is:

Native select gets the Select class; custom React dropdowns get click-wait-click; file upload is sendKeys on the input—never robot typing into OS dialogs in CI.

Python Selenium is valid—see Python developer interviews—but java selenium interview questions appear most often in corporate SDET loops. Know Java OOP from Java part one and part two.

A strong answer is:

Java fits enterprise POM frameworks, Maven CI, and TestNG parallel suites—it's what most teams I interview with already run, even if I'd use Python for a greenfield smaller stack.

@Test(priority = 1, groups = {"smoke"})
public void loginTest() { /* ... */ }

Run groups in CI: mvn test -Dgroups=smoke.

A strong answer is:

BeforeMethod opens and closes the browser per test for isolation; BeforeClass when setup is expensive and tests are read-only—I know which annotation matches my isolation needs.

Best practice: @BeforeMethod creates driver; @AfterMethod quits—cleanest for parallel methods.

A strong answer is:

I default to BeforeMethod driver lifecycle for isolation; BeforeClass only when tests are independent and share expensive read-only setup—not a shared logged-in session unless I design for it.

@DataProvider supplies rows of arguments to the same test logic—login with many credentials, checkout with many products.

@DataProvider(name = "users")
public Object[][] users() {
    return new Object[][] {
        {"[email protected]", "pass1", true},
        {"[email protected]", "pass2", false}
    };
}

@Test(dataProvider = "users")
public void login(String email, String password, boolean expectSuccess) {
    // drive UI with email/password; assert expectSuccess
}

Data can come from JSON, CSV, Excel, or DB—keep providers in separate classes for large sets.

A strong answer is:

DataProvider keeps one test method and many data rows—I'd externalize large sets to JSON or CSV and validate provider size in CI so empty files don't silently skip coverage.

Configure testng.xml:

<suite name="ParallelSuite" parallel="methods" thread-count="4">
  <test name="UI Tests">
    <classes>
      <class name="com.example.tests.LoginTest"/>
    </classes>
  </test>
</suite>

WebDriver is not thread-safe—never share one driver across threads. Use ThreadLocal (next question) or one instance per parallel <test>.

A strong answer is:

parallel=methods with thread-count matched to Grid capacity—each thread gets its own driver via ThreadLocal, never a static shared WebDriver field.

WebDriver instances are not thread-safe. A static driver field in parallel runs causes random clicks in the wrong browser session.

Pattern:

public class DriverFactory {
    private static final ThreadLocal<WebDriver> driver = new ThreadLocal<>();

    public static WebDriver getDriver() { return driver.get(); }
    public static void setDriver(WebDriver d) { driver.set(d); }
    public static void removeDriver() {
        if (driver.get() != null) driver.get().quit();
        driver.remove();
    }
}

The runnable simulation below models per-thread isolation without Selenium on the classpath—each thread gets its own session id:

import java.util.*;
import java.util.concurrent.*;

public class ThreadLocalDriverSim {
    private static final ThreadLocal<String> SESSION = new ThreadLocal<>();

    static String runTest(int id) {
        SESSION.set("session-" + id);
        return Thread.currentThread().getName() + " -> " + SESSION.get();
    }

    public static void main(String[] args) throws Exception {
        ExecutorService pool = Executors.newFixedThreadPool(3);
        List<Future<String>> futures = new ArrayList<>();
        for (int i = 1; i <= 3; i++) {
            final int n = i;
            futures.add(pool.submit(() -> runTest(n)));
        }
        for (Future<String> f : futures) System.out.println(f.get());
        pool.shutdown();
    }
}

Each printed line pairs a thread name with its own session-N value—no cross-thread bleed.

A strong answer is:

ThreadLocal gives each parallel thread its own driver; I always quit and remove in AfterMethod so threads don't leak sessions or memory in long CI jobs.

SoftAssert soft = new SoftAssert();
soft.assertEquals(actualTitle, "Dashboard");
soft.assertTrue(isLogoutVisible);
soft.assertAll();

Do not put assertions inside Page Object methods—keep them in test classes so pages stay reusable UI APIs.

A strong answer is:

Hard assert on gates that make later steps meaningless; SoftAssert on one page with many field checks—and assertions stay in tests, not page objects.

POM maps each page (or component) to a class that:

1. Holds locators as private fields (By or WebElement lazy)
2. Exposes action methods (login(user, pass), openSettings())
3. Avoids assertions — tests assert outcomes

Anti-pattern: test methods full of driver.findElement—that is a script, not POM.

A strong answer is:

POM encapsulates locators and actions per page; tests read like scenarios and assert results—when the login button moves, I fix one class, not forty tests.

Page Factory initializes page objects with @FindBy annotations—Selenium lazy-loads elements on use.

public class LoginPage {
    @FindBy(id = "username")
    private WebElement username;

    public LoginPage(WebDriver driver) {
        PageFactory.initElements(driver, this);
    }

    public void enterUsername(String user) {
        username.sendKeys(user);
    }
}

Many teams use manual By locators + explicit waits for SPAs; Page Factory suits simpler pages.

A strong answer is:

Page Factory speeds boilerplate on stable pages; for dynamic SPAs I prefer manual By locators relocated inside WebDriverWait to control stale behavior.

No — page objects should interact, tests should verify.

Returning state (String, boolean) keeps pages usable from different test scenarios.

A strong answer is:

Page objects return state or perform actions; tests assert—mixing Assert into pages couples UI to one expected outcome and ruins reuse.

Modern hybrid stack: Maven + TestNG + POM + JSON/CSV data + Extent/Allure reporting + CI.

Keyword-driven alone adds indirection—interviewers may ask when it stopped helping maintainability.

A strong answer is:

I ship hybrid—POM for structure, DataProvider or external data for rows—keyword sheets only when non-coders must author cases and we invest in a solid engine.

Pattern: API or DB seed in @BeforeMethod for complex state; static JSON for login matrices. Always clean up or use isolated tenants.

A strong answer is:

JSON in Git for login matrices; API setup for orders or payments; I never rely on production data and I tear down or use disposable accounts per run.

On failure, capture screenshot, page source (trimmed), browser logs, and current URL in @AfterMethod or a TestNG listener.

@AfterMethod
public void tearDown(ITestResult result) {
    if (result.getStatus() == ITestResult.FAILURE) {
        // capture screenshot to reports folder
    }
    DriverFactory.removeDriver();
}

A strong answer is:

TestNG XML for CI gates; Extent or Allure for humans—I attach screenshots and URL on failure so triage doesn't require reproducing locally first.

src/test/java/
  base/          BaseTest, DriverFactory, listeners
  pages/         Page objects
  tests/         TestNG test classes
  utils/         Config reader, Excel/JSON helpers
src/test/resources/
  config.properties
  testdata/
  testng.xml
pom.xml          selenium-java, testng, webdrivermanager

Key pom.xml dependencies: selenium-java, testng (test scope), optional webdrivermanager or rely on Selenium Manager. Run via mvn clean test or mvn test -DsuiteXmlFile=testng.xml—see Maven interviews for lifecycle and surefire plugin questions.

A strong answer is:

I separate base, pages, tests, and resources—Maven surefire runs testng.xml in CI with browser version pins and test-scoped dependencies only.

Grid 4 distributes browser sessions across nodes—one hub/router coordinates; nodes host browsers.

Test → Grid Router → Node (Chrome) / Node (Firefox)

Tests point RemoteWebDriver at the Grid URL with desired capabilities:

ChromeOptions options = new ChromeOptions();
WebDriver driver = new RemoteWebDriver(new URL("http://grid:4444"), options);

A strong answer is:

Grid scales browsers horizontally—my tests use RemoteWebDriver against the router, and I size nodes to match peak parallel thread-count, not one giant machine.

Official images (selenium/standalone-chrome, selenium/node-chrome, hub/router stacks) spin browsers in containers—common in Kubernetes or docker-compose CI agents.

Benefits:

• Reproducible browser versions
• Isolated sessions per container
• Scale nodes elastically

Watch memory—Chrome containers need RAM per session; oversubscribing causes OOM kills and mystery flakes.

A strong answer is:

Docker Grid gives pinned browsers in CI—I cap parallel sessions per node based on RAM and use health checks so dead nodes don't accept sessions.

Align with Git interview questions for branch strategy—run smoke on feature branches, full suite on main merge.

A strong answer is:

Smoke parallel on every PR with artifacts on failure; full regression scheduled—I fail the build on smoke red but don't block merges on a two-hour suite without triage rules.

Debug flow: reproduce headed → add logging → check screenshot/video → tighten wait → quarantine chronic flake until fixed (don't mute forever).

A strong answer is:

Flakes are usually timing or shared state—I fix with explicit waits and per-test drivers, capture artifacts on failure, and quarantine chronic offenders instead of rerunning until green.

TestNG ITestResult in @AfterMethod or ITestListener:

if (result.getStatus() == ITestResult.FAILURE) {
    File src = ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE);
    Files.copy(src.toPath(), Path.of("reports/" + result.getName() + ".png"));
}

Cloud grids (BrowserStack, Sauce Labs) often provide video and network logs automatically—worth the cost for hard-to-reproduce UI bugs.

A strong answer is:

Screenshot plus URL and timestamp on every failure; video when the grid provides it—I attach paths to Extent or Allure so CI artifacts tell the story without local repro.

Use capabilities or options objects per browser—not copy-paste test classes. Parameterize browser from TestNG @Parameters or @DataProvider.

A strong answer is:

One test class parameterized by browser—Chrome daily, Firefox and Edge on nightly Grid—Safari on cloud macOS because Linux agents can't run it natively.

Cloud gives real devices and version matrices without maintaining dozens of VMs—cost per minute matters at scale.

A strong answer is:

Self-hosted Grid for high-volume Chrome/Firefox in CI; cloud for Safari, mobile WebView, and legacy IE matrices we don't want to host—choice is ops cost vs coverage breadth.

Design layers:

1. Test (LoginTest) — data, assertions, TestNG annotations
2. Page (LoginPage) — locators, enterCredentials, clickLogin
3. Base (BaseTest) — driver lifecycle, URL from config
4. Wait — dashboard element visible after submit
5. Negative case — error message via DataProvider
6. Report — screenshot on failure

@Test
public void validLogin() {
    LoginPage login = new LoginPage(DriverFactory.getDriver());
    login.open(baseUrl + "/login");
    login.login("[email protected]", "secret");
    assertTrue(new DashboardPage(driver).isLoaded());
}

Discuss test data isolation—create user via API if registration is required; don't depend on shared prod accounts.

A strong answer is:

I'd sketch POM layers, explicit wait on dashboard load, DataProvider for bad passwords, API-seeded user, and screenshot on failure—tests assert, pages act.

Checklist:

• Draw WebDriver architecture (bindings → driver → browser)
• Explain W3C protocol in Selenium 4
• Locator priority and CSS vs XPath
• Explicit wait example; why not Thread.sleep
• ThreadLocal for parallel TestNG
• POM rules — no assertions in pages
• testng.xml parallel settings
• Grid vs cloud one-liner
• One flake story and one CI story
• Java fundamentals for OOP questions
• Maven for mvn test and surefire
• Computer networks for HTTP/DNS behind WebDriver

A strong answer is:

I rehearse architecture, waits, POM, and ThreadLocal on a whiteboard, then walk through a real suite I stabilized—flakes fixed, runtime cut with parallel Grid—not definitions without war stories.