Selenium Interview Questions and Answers

Selenium WebDriver is an API that controls a real browser from test code. Your script never talks to the browser directly. It goes through a driver.

Flow:

• Test code (Java, Python, C# and others) uses the language bindings.
• The bindings send commands as HTTP requests using the W3C WebDriver protocol.
• A browser driver (chromedriver, geckodriver, msedgedriver) receives them.
• The driver controls the real browser and sends back a JSON response (success, element, or error).

Since Selenium 4, the protocol is the W3C standard. There is no JSON Wire translation layer, so browsers behave more the same way.

What they are checking: Whether you understand the full chain of client, protocol, driver and browser, not just the API

Selenium 4 moved fully to the W3C WebDriver standard. It also added these features:

• Relative locators (above, below, toLeftOf, toRightOf, near).
• newWindow(WindowType.TAB / WINDOW) opens and switches to a new tab or window in one call.
• Chrome DevTools Protocol access (network interception, console logs, geolocation, performance) for Chromium browsers.
• A redesigned Selenium Grid with Hub, Node, Router, Distributor, Session Map and Event Bus. It also has Docker support and better monitoring.
• Element screenshots, and full page screenshots in Firefox.
• Selenium Manager (4.6 and later) downloads the matching drivers for you.
• A better Actions API and updated documentation.

What they are checking: Whether you follow changes in the tool's versions and know what is really new

Selenium has eight strategies: id, name, className, tagName, linkText, partialLinkText, CSS selector and XPath.

My order of preference:

• id when it is unique and stable. It is the fastest and the clearest.
• A dedicated test attribute such as data-testid through CSS ([data-testid='submit']). It does not change when the styling changes.
• CSS selectors for most other cases. They are fast and easy to read.
• XPath only when I need text matching, parent or sibling search, or something CSS cannot do.

I avoid long absolute paths, auto-generated ids and class names that come from a styling framework.

What they are checking: Whether you pick locators for stability and easy maintenance, not out of habit

Both find elements. They differ in power and speed.

Use CSS by default. Use XPath when you need to go to a parent or match visible text.

What they are checking: Whether you can explain your choice with real trade-offs

• Implicit wait: a global timeout. For any element search, the driver keeps trying up to that time before it throws NoSuchElementException. Set it once with driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10)).
• Explicit wait: WebDriverWait with an ExpectedCondition for one specific case (visible, clickable, text present). It works only where you write it.
• Fluent wait: an explicit wait with your own polling interval and a list of exceptions to ignore.

Best practice: use explicit waits to sync with the page. Do not mix them with implicit waits, because the total wait time becomes hard to predict.

What they are checking: Whether you can sync tests reliably and know the risk of mixing waits

It means the element you hold is no longer attached to the DOM. The page may have re-rendered, moved to another page, or JavaScript replaced the node. The old reference is dead, even if an identical element is visible.

Fixes:

• Find the element again just before you use it. Do not keep it for a long time.
• Wait for the condition that shows the refresh is done, for example ExpectedConditions.refreshed(ExpectedConditions.elementToBeClickable(locator)).
• Store locators (By) instead of WebElement objects. Page Object Model with lazy lookups does this.
• As a last resort, add a small retry. Do not add a blanket sleep.

What they are checking: Whether you understand why it happens, not only how to retry

Page Object Model (POM) puts each page or component into a class. The class gives actions and hides locators. Tests call methods like login_page.sign_in(user, pwd) and never use locators directly.

Benefits:

• When the UI changes, you edit one class, not 50 tests.
• Tests read like business steps.
• Less repeated code and better reuse.

class LoginPage:
    USER = (By.ID, "username")
    PWD = (By.ID, "password")
    SUBMIT = (By.CSS_SELECTOR, "button[type=submit]")
    def __init__(self, driver): self.driver = driver
    def sign_in(self, user, pwd):
        self.driver.find_element(*self.USER).send_keys(user)
        self.driver.find_element(*self.PWD).send_keys(pwd)
        self.driver.find_element(*self.SUBMIT).click()

Keep assertions in tests, not in page objects.

What they are checking: Whether you can design test code that is easy to maintain

Avoid the attribute that changes. Use something stable instead.

• Partial match: //input[starts-with(@id,'user_')], contains(@id,'email'), or CSS input[id^='user_'], [id$='_email'], [id*='email'].
• Use a stable parent, label or text: //label[text()='Email']/following-sibling::input.
• Use test attributes (data-testid) and ask developers to add them.
• Use aria-label, name, or placeholder when they are stable.
• Combine conditions: //button[contains(@class,'primary') and normalize-space()='Pay'].

Always find the element again after the page updates. Wait for the element to be present.

What they are checking: Whether you can write locators that do not break easily

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

class LoginPage:
    URL = "https://the-internet.herokuapp.com/login"
    def __init__(self, driver):
        self.driver = driver
        self.wait = WebDriverWait(driver, 10)
    def open(self):
        self.driver.get(self.URL)
        return self
    def login(self, user, pwd):
        self.driver.find_element(By.ID, "username").send_keys(user)
        self.driver.find_element(By.ID, "password").send_keys(pwd)
        self.driver.find_element(By.CSS_SELECTOR, "button[type=submit]").click()
    def flash(self):
        return self.wait.until(EC.visibility_of_element_located((By.ID, "flash"))).text

@pytest.fixture
def driver():
    d = webdriver.Chrome()
    yield d
    d.quit()

def test_valid_login(driver):
    page = LoginPage(driver).open()
    page.login("tomsmith", "SuperSecretPassword!")
    assert "You logged into a secure area" in page.flash()

def test_invalid_login(driver):
    page = LoginPage(driver).open()
    page.login("tomsmith", "wrong")
    assert "Your password is invalid" in page.flash()

What they are checking: Whether you can write a clean test that runs, during a live exercise

Absolute XPath starts at the root with a single slash and lists every node, for example /html/body/div[2]/form/input[1]. Any small layout change breaks it.

A fixed sleep waits the full time even when the page is ready. It still fails when the page is slower than the sleep. That makes test suites both slow and unstable (tests that pass sometimes and fail other times).

For a standard <select> element, use the Select class:

Switch to the alert and act on it. After that, control goes back to the page automatically:

The driver cannot see elements inside an iframe until you switch context.

Each window has a handle. Save the original handle, open the new window, and wait for it. Then switch to it, and switch back at the end.

• findElement returns the first matching WebElement. It throws NoSuchElementException if there is none.
• findElements returns a list of all matches. If nothing matches, it returns an empty list and throws no exception.

• close() closes only the current window or tab that the driver is focused on.
• quit() closes all windows and ends the driver session. It also shuts down the driver process.

Order from outermost to innermost: @BeforeSuite -> @BeforeTest -> @BeforeClass -> @BeforeMethod -> @Test -> @AfterMethod -> @AfterClass -> @AfterTest -> @AfterSuite.

Useful attributes of @Test: priority, dependsOnMethods, enabled, groups, invocationCount, retryAnalyzer, dataProvider.

Both open a URL and wait for the page load event. The difference is that navigate() returns a Navigation object. It also supports back(), forward() and refresh(). get() only loads a URL. get() is simpler for the first load. Use navigate() when you need browser history actions in the same flow.

• It works with web browsers only. For native desktop or mobile apps, you need Appium.
• It has no built-in reporting, test runner or parallel framework. You add them yourself.
• It cannot directly automate CAPTCHAs, OS-level dialogs, or barcode and OTP flows.
• It has no native image comparison.
• Dynamic pages need explicit waits. So it needs more sync code than newer tools like Playwright.
• Driver and browser versions must match (Selenium Manager reduces this problem).

Actions builds complex user actions: hover, drag and drop, right click, double click, key combinations and click-and-hold.

A pytest fixture creates and cleans up a resource such as the driver. Tests ask for it by argument name.

JavascriptExecutor runs JavaScript in the page. Use it when WebDriver commands are not enough:

• Scroll: driver.execute_script("arguments[0].scrollIntoView(true);", el).
• Click an element that WebDriver says is blocked (last resort, because it skips real user behaviour).
• Read values that the DOM gives only through JS, or set a value on a read-only date input.
• Get page state, for example return document.readyState.

Grid 4 lets you run tests on many machines and browsers at the same time. It has three modes: Standalone (one process), Hub and Node, and fully distributed.

Two things are needed: a runner that runs tests in parallel, and safe driver handling for each thread.

Keep the test logic apart from the test data. Run the same test with many rows of data.

Run them headless in a clean environment that you can repeat, on each pull request or merge.

A WebDriver instance is not thread-safe, so each thread needs its own.

In Java, use a ThreadLocal:

Pass a headless flag through the browser options.

Use get_screenshot_as_file (or TakesScreenshot in Java) in a failure hook.

In pytest, a hook in conftest.py can attach it:

Upload: if there is an <input type='file'>, send the absolute path with send_keys. You do not need to use any dialog.

Selenium 4 supports shadow roots directly. Find the host element, get its shadow root, then search inside it.

Make the browser a setting in the driver factory. Run the same suite on each browser.

Before Selenium 4.6, you downloaded chromedriver by hand or used a library like WebDriverManager. The driver version had to match the installed browser.

Relative locators find elements by their position next to another element. They use with_tag_name and above, below, to_left_of, to_right_of, near.

Selenium 4 gives access to the DevTools Protocol for Chromium browsers (Chrome, Edge). It lets you do things WebDriver cannot:

• Intercept and mock network requests, or block resources.
• Capture console logs and JavaScript errors.
• Copy device sizes, geolocation and slow networks.
• Collect performance numbers.

I would treat unstable tests as a defect, not as noise. First I find the category.

1. Collect evidence: rerun the failing test 20 times. Capture screenshots, page source, browser console and network logs. Note the pass rate for each environment.
2. Find the cause:
   • Timing: missing waits, animations, async rendering. Fix with explicit conditions, not sleeps.
   • Test data: shared accounts, order dependence, leftover state. Create data for each test and clean it up.
   • Locators: unstable ids, stale elements.
   • Environment: slow CI, shared test server, third-party calls. Mock external services.
   • A real race condition in the product. Report it as a bug.
3. Fix the root cause. Then put any still-unstable test in quarantine with a tag so it stops blocking the pipeline. Keep a list of quarantined tests.
4. Prevent it: run new tests many times before merging. Track the failure rate on a dashboard.

Automatic retries only hide the problem. I allow one retry at most while the root cause is being fixed.

What they are checking: Whether you have a clear method and do not hide unstable tests with retries

I compare the two environments and make the CI failure easy to see.

It means another element covers the target at the click point. Examples are a cookie banner, spinner, sticky header or modal.

The element is in the DOM but cannot take the action. It may be hidden, zero size, disabled, off-screen, or not yet drawn.

I would measure first. Then I would fix the biggest costs.

The assertion runs before the page finishes updating. So the test races the application.

You do not automate the CAPTCHA itself. You remove it from the test path.

I would recommend it when the team has unstable tests (tests that pass sometimes and fail other times) and slow suites on modern JavaScript apps. It also fits when the team needs built-in tracing, network mocking, and fast parallel runs, and is happy with Chromium, Firefox and WebKit only.