Selenium is the most widely used tool for web test automation. These Selenium interview questions cover WebDriver, locators and basic commands for freshers, then waits, handling frames, windows and alerts, the Page Object Model, TestNG, Selenium Grid, flaky tests and framework design for experienced automation testers.
30 questions · Updated
Fundamentals, definitions and simple scenarios. Good for freshers and warm-ups.
Selenium is an open-source suite for automating web browsers for testing.
Selenium WebDriver drives browsers through their native drivers and supports Java, Python, C#, JavaScript and more.
Selenium IDE is a browser extension for record and playback.
Selenium Grid runs tests in parallel across many browsers and machines.
ID, name, className, tagName, linkText, partialLinkText, CSS selector and XPath.
ID is the fastest and most reliable when it is unique and stable.
CSS selectors are fast and readable.
XPath is the most flexible, able to navigate up to parents and match by text, but long absolute XPaths break easily.
I prefer stable attributes such as data-testid agreed with developers.
findElement returns the first matching element and throws NoSuchElementException if none is found. findElements returns a list of all matching elements and returns an empty list if none is found, so it is useful to check whether an element exists without an exception.
Selenium 4 uses the W3C WebDriver standard for communication with browsers, adds relative locators (above, below, near, toLeftOf), better window and tab handling with newWindow, element screenshots, access to Chrome DevTools features, a redesigned Grid, and Selenium Manager, which downloads the right browser drivers automatically.
Your test code calls the Selenium client library, which sends commands over HTTP using the W3C WebDriver protocol to a browser driver, such as chromedriver or geckodriver.
The driver controls the real browser and returns results.
Selenium Manager finds or downloads matching drivers.
WebDriver BiDi is a newer bidirectional protocol for events such as console logs and network activity.
For a standard HTML select element, wrap it in the Select class and use selectByVisibleText, selectByValue or selectByIndex, getOptions to list options and getFirstSelectedOption to read the selection. Custom dropdowns built from div and li elements are not real selects, so you click to open them and then click the option, waiting for it to appear.
The Actions class performs complex user interactions: hovering with moveToElement, right-clicking with contextClick, double-clicking, drag and drop, clicking and holding, and keyboard combinations such as holding Shift while clicking.
Actions are chained and executed with perform().
Hover menus and drag-and-drop interfaces are typical uses.
Cast the driver to TakesScreenshot and call getScreenshotAs(OutputType.FILE) or BYTES, then save the file; Selenium 4 can also capture a single element. Screenshots are usually taken automatically when a test fails, using a TestNG listener or JUnit extension, and attached to reports such as Allure to help debug failures.
getText() returns the visible text of an element, getAttribute or getDomAttribute and getDomProperty read attribute and property values, such as the value of an input, and getCssValue reads computed styles. isDisplayed, isEnabled and isSelected check state. Assertions then compare these values with the expected results.
Both open a URL and wait for the page to load. driver.get() is the common way to open a page. driver.navigate() also provides back(), forward() and refresh() to move through browser history. In practice navigate().to() and get() behave the same in modern Selenium.
close() closes the current browser window or tab only; if it was the last window, the browser session may remain. quit() closes all windows and ends the WebDriver session, freeing resources. Tests should call quit() in teardown (for example @AfterMethod), otherwise leftover browser processes slow down or crash the test machine.
Applied problems, trade-offs and questions about your own projects.
An implicit wait sets a global time for findElement to keep looking for elements.
An explicit wait uses WebDriverWait with ExpectedConditions to wait for a specific condition, such as an element being clickable.
A fluent wait is an explicit wait with a custom polling interval and exceptions to ignore.
I use explicit waits and avoid mixing them with implicit waits or using Thread.sleep.
For frames, driver.switchTo().frame() by index, name or element, and defaultContent() to return.
For windows, getWindowHandles() returns all handles; I switch with switchTo().window(handle) and switch back after.
For JavaScript alerts, switchTo().alert() with accept(), dismiss(), getText() or sendKeys().
The Page Object Model is a design pattern where each page or component has a class containing its locators and methods for user actions, such as LoginPage.login(user, password).
Tests call these methods instead of using locators directly.
When the UI changes, only the page class needs updating, which makes tests readable and maintainable.
TestNG provides annotations such as @BeforeMethod, @Test and @AfterMethod to set up and tear down, assertions, groups, priorities, dependencies, parameterisation with @DataProvider, parallel execution and listeners.
Test suites are configured in testng.xml, and reports and screenshots on failure are added through listeners.
JUnit 5 is a common alternative.
Use functions and axes instead of absolute paths: contains(@id, "user") for partial matches, starts-with, text()="Login" or normalize-space() for visible text, and axes such as following-sibling, preceding-sibling, parent and ancestor to locate elements relative to stable ones, such as //label[text()="Email"]/following-sibling::input. Combining conditions with and keeps locators precise.
JavascriptExecutor runs JavaScript in the browser, for actions WebDriver cannot do directly: scrolling an element into view, clicking an element hidden behind an overlay, reading values from the DOM, changing attributes or working with complex custom widgets. It should be a last resort, because it bypasses real user behaviour and can hide genuine bugs.
For uploads, send the file's absolute path to the input type="file" element with sendKeys, which works even in headless mode without opening the operating system dialog.
For downloads, configure browser options to save automatically to a known folder without a prompt, then wait for the file to appear and verify it.
Remote Grid nodes need a file detector or the Grid download feature.
It happens when an element you found earlier is no longer attached to the page, because the page reloaded, a framework re-rendered that part of the DOM, or you navigated away. The fix is to find the element again right before using it, wait for the page to settle with explicit waits, and use page objects that locate elements when needed rather than storing them.
Headless mode runs the browser without a visible window, enabled through options such as --headless=new for Chrome.
It is faster and suits CI servers without a display.
Some behaviour can differ, such as window size defaulting smaller, so set an explicit window size and occasionally run tests headed to debug visual problems.
Keep test data separate from test logic and run the same test with many data sets.
TestNG's @DataProvider or JUnit's @ParameterizedTest supply the data, read from Excel with Apache POI, CSV, JSON or a database.
This covers many input combinations, such as valid and invalid logins, without duplicating test code.
Write tests against the WebDriver interface and choose the browser from configuration or a parameter, creating ChromeDriver, FirefoxDriver, EdgeDriver or SafariDriver in a driver factory. Run them in parallel on Selenium Grid, Docker containers or cloud platforms such as BrowserStack or LambdaTest, which also provide real mobile devices and many browser versions.
System design, deep internals, leadership and tough follow-ups.
Common causes are timing issues and fixed sleeps, unstable locators, tests that depend on each other or on shared data, animations, and unreliable test environments. I fix them with explicit waits for real conditions, stable data-testid locators, independent tests that create their own data, retrying only for genuine infrastructure failures, and running tests in clean, consistent environments.
I use the Page Object Model with a base page and a driver factory that supports different browsers and runs locally or on Grid, configuration from properties or environment variables, test data in external files or builders, utility classes for waits and screenshots, TestNG or JUnit for execution, and Maven or Gradle for builds. It produces Allure or Extent reports and runs in CI on every build, in parallel.
Selenium Grid runs tests on remote machines across multiple browsers and operating systems in parallel.
In Selenium 4, a router receives requests and a distributor sends them to nodes with the requested browser.
Tests use RemoteWebDriver with browser options.
Grid is often run with Docker containers, or replaced by cloud services such as BrowserStack or LambdaTest.
Cucumber supports behaviour-driven development: scenarios are written in Gherkin feature files with Given, When and Then steps in plain English that business people can read.
Step definitions map each step to code that uses page objects and Selenium.
Hooks handle setup and teardown, tags select scenarios to run, and scenario outlines with examples tables provide data-driven tests.
The pipeline, in Jenkins, GitHub Actions or GitLab CI, checks out the code, builds it, starts the application or uses a test environment, and runs tests in headless browsers or against Selenium Grid in Docker, in parallel.
It publishes reports and screenshots, and fails the build on test failures.
Quick smoke tests run on every commit and the full regression suite nightly.
Selenium supports the most languages and browsers and is a W3C standard, with a large ecosystem, but needs more setup and explicit waits.
Playwright has automatic waiting, fast parallel execution, network interception and built-in tracing, supporting several languages and browsers.
Cypress runs inside the browser with great debugging for JavaScript apps but has limits with multiple tabs and origins.
Many new projects choose Playwright.
CAPTCHAs are designed to block bots, so in test environments they should be disabled or use test keys.
For OTPs, use test numbers, a backdoor API, or read codes from a test email or SMS service.
To save time, log in once through an API and inject the session cookie or token into the browser, rather than going through the login page in every test.
Elements inside a Shadow DOM are not reachable with normal locators.
In Selenium 4, find the host element, call getShadowRoot() to get a SearchContext, and then find elements inside it with CSS selectors (XPath is not supported inside shadow roots).
Nested shadow roots need this step repeated for each level.
See all QA Engineer interview questions, covering Manual Testing, Test Cases & Test Plans, Selenium, Cypress, Playwright and more.