Selenium remains the most installed browser automation tool in the industry, and it’s still the backbone of regression testing at a huge share of enterprise QA teams. But Selenium interviews in 2026 go well past “what is a locator.” Panels now expect you to explain W3C WebDriver architecture, defend explicit waits over blind sleeps, walk through a real framework design, and articulate when a newer tool like Playwright actually makes more sense than Selenium for a given project.

This guide covers 60 of the most frequently asked Selenium interview questions, organized by experience level, from the fundamentals every fresher should know through the Selenium 4 features (relative locators, native DevTools support, the WebDriver BiDi protocol, and the redesigned Grid) that now show up constantly in 2026-specific rounds, plus a dedicated section on how Selenium stacks up against Playwright and Cypress. Whether you’re prepping for your first QA role or a senior SDET interview, this is built to get you ready.

Beginner-Level Selenium Interview Questions (Fundamentals)

1. What is Selenium?

Selenium is an open-source suite of tools for automating web browsers, used primarily for testing web applications across different browsers and platforms. It isn’t a single product but a collection of components: Selenium WebDriver (the core automation API), Selenium IDE (a record-and-playback browser extension), and Selenium Grid (for distributed, parallel test execution).

2. What are the main components of the Selenium suite?

Selenium WebDriver drives browser interaction directly through browser-specific driver binaries. Selenium IDE lets testers record and replay simple browser actions without writing code, useful for quick prototyping. Selenium Grid distributes test execution across multiple machines and browsers in parallel, cutting down total suite runtime. Selenium RC (Remote Control), the original component, was deprecated years ago and has since been fully retired, so mentioning that it’s obsolete is itself a small signal of current knowledge in an interview.

3. What is Selenium WebDriver, and how does it actually communicate with a browser?

WebDriver sends commands to a browser-specific driver binary (ChromeDriver for Chrome, GeckoDriver for Firefox, EdgeDriver for Edge) over HTTP, following the W3C WebDriver protocol. Your test code never controls the browser directly; the driver binary translates each WebDriver command into native browser automation calls.

4. Which programming languages does Selenium support?

Selenium officially supports Java, Python, C#, Ruby, and JavaScript (Node.js) through its language bindings. Java remains the dominant choice in enterprise QA teams, often paired with TestNG or JUnit, while Python has grown significantly for smaller teams and SDETs coming from a data or scripting background.

5. What is a locator in Selenium?

A locator is a strategy for identifying a specific element on a web page so Selenium can interact with it. Common locator types include ID, name, class name, tag name, link text, CSS selector, and XPath, with ID and CSS selectors generally preferred for both speed and stability when a unique, stable attribute is available.

6. What’s the difference between CSS selectors and XPath?

CSS selectors are generally faster and easier to read, and they’re the preferred choice when an element has a stable ID or class. XPath is more powerful for complex cases, since it can traverse both up and down the DOM tree (for example, selecting a parent based on a child element), which CSS selectors cannot do natively.

7. What are relative locators in Selenium 4?

Relative locators, introduced in Selenium 4, let you locate an element based on its position relative to another element, using methods like above(), below(), toLeftOf(), toRightOf(), and near(). They’re particularly useful for dynamic UIs where traditional locators are unstable but visual positioning relative to a known element stays consistent.

8. What is the difference between findElement() and findElements()?

findElement() returns a single WebElement matching the locator and throws a NoSuchElementException if nothing matches. findElements() returns a list of all matching elements, returning an empty list rather than throwing an exception if none are found, which makes it useful for existence checks without wrapping code in a try-catch block.

9. What is the difference between close() and quit() in WebDriver?

close() closes only the current browser window or tab that the driver is focused on. quit() closes all windows associated with that WebDriver session and properly ends the driver process itself, which is why quit() should generally be called in test teardown to avoid leaving orphaned browser processes running.

10. What is Selenium Manager?

Selenium Manager is a tool built directly into Selenium 4 that automatically detects your installed browser version and downloads the matching driver binary, removing the manual driver version management that used to be a constant source of setup friction and CI pipeline breakage in earlier Selenium versions.

11. Can Selenium test mobile applications?

Not directly. Selenium is built for browser automation, not native mobile apps. Appium, which is built on WebDriver protocol principles and shares conceptual similarities with Selenium, is the standard tool for mobile app automation, and many Selenium-experienced testers pick it up relatively quickly given the shared underlying architecture.

12. What is the difference between implicit and explicit waits?

An implicit wait is a global setting applied to every element lookup for the entire WebDriver session, telling Selenium to wait a set amount of time before throwing an exception if an element isn’t immediately found. An explicit wait (using WebDriverWait) targets one specific condition for one specific element, such as waiting for an element to become clickable. Mixing implicit and explicit waits in the same test suite is a well-known source of unpredictable timing bugs and is generally avoided.

13. Why are hardcoded Thread.sleep() calls discouraged in Selenium tests?

Thread.sleep() pauses execution for a fixed duration regardless of whether the page or element is actually ready, which wastes time when the page loads faster than expected and still fails when it loads slower. Explicit waits react to actual page state instead, making tests both faster on average and more reliable.

14. What is a WebElement?

A WebElement is an object representing a single HTML element on a page (a button, input field, link, or similar) that Selenium can interact with: clicking, typing text, reading attributes, or checking visibility and enabled state.

15. How do you handle a dropdown in Selenium?

For standard HTML <select> dropdowns, Selenium’s Select class provides methods like selectByVisibleText(), selectByValue(), and selectByIndex(). For custom dropdowns built with JavaScript frameworks rather than a native <select> tag, you typically need to click the dropdown to open it, then locate and click the specific option element directly, since the Select class only works with true HTML select elements.

Intermediate-Level Selenium Interview Questions

16. What is the Page Object Model (POM), and why is it used?

Page Object Model is a design pattern where each web page (or major component) is represented by a dedicated class containing that page’s locators and interaction methods. This separates test logic from page structure, so when the UI changes, you update locators in one page class rather than hunting through every test that touches that page.

17. Should assertions live inside Page Object classes?

Generally no. Page classes should expose actions and return state (like whether an element is displayed, or the text of a field), while assertions belong in the test methods themselves. Mixing assertions into page objects blurs the separation of concerns POM is meant to provide and makes page classes harder to reuse across different test scenarios with different expected outcomes.

18. What is a fluent wait, and how does it differ from an explicit wait?

A fluent wait is essentially a more configurable explicit wait, letting you set a custom polling frequency and specify which exceptions to ignore while waiting (like NoSuchElementException during repeated polling attempts). It’s useful when an element’s appearance timing is unpredictable and you want tighter control over how often Selenium re-checks.

19. What is a StaleElementReferenceException, and what causes it?

This exception occurs when a previously located WebElement is no longer attached to the current DOM, typically because the page refreshed, an AJAX call re-rendered part of the page, or JavaScript rebuilt the element. The fix is usually to re-locate the element right before interacting with it rather than reusing a reference captured earlier in the test.

20. How do you handle multiple browser windows or tabs in Selenium?

WebDriver’s getWindowHandles() method returns the identifiers of all open windows, and switchTo().window(handle) moves control to a specific one. This is commonly needed when an action (like clicking a link) opens a new tab that the test then needs to interact with before switching back to the original window.

21. How do you handle iframes in Selenium?

WebDriver’s switchTo().frame() method moves control into a specific iframe, using its index, name, ID, or a WebElement reference. Elements inside an iframe aren’t accessible until you’ve explicitly switched into that frame, and you need switchTo().defaultContent() to return to the main page afterward.

22. What is TestNG, and why is it commonly used with Selenium?

TestNG is a testing framework for Java that adds features Selenium itself doesn’t provide: test annotations (@Test, @BeforeMethod, @AfterMethod), grouping and prioritizing tests, parallel test execution, data-driven testing through @DataProvider, and built-in HTML reporting. It’s one of the two dominant frameworks (alongside JUnit) paired with Selenium in Java-based automation.

23. How do you achieve data-driven testing in Selenium?

Data-driven testing runs the same test logic against multiple sets of input data, commonly implemented in TestNG using @DataProvider, or by reading test data from external sources like Excel files, CSV files, or JSON. This avoids duplicating nearly identical test methods that differ only in their input values.

24. How do you take a screenshot in Selenium?

WebDriver’s TakesScreenshot interface provides a getScreenshotAs() method to capture the current browser state as an image file, commonly used to capture evidence of test failures automatically in a test’s teardown or exception-handling logic, which speeds up debugging significantly compared to relying only on log output.

25. How do you handle JavaScript alerts and pop-ups in Selenium?

WebDriver’s switchTo().alert() gives you control over native browser alerts, letting you call accept() to click OK, dismiss() to click Cancel, getText() to read the alert’s message, or sendKeys() to enter text into a prompt-style alert.

26. What is the difference between driver.get() and driver.navigate().to()?

Both load a URL in the browser, but navigate() also provides additional browser navigation methods like back(), forward(), and refresh(), giving it slightly more functionality beyond a simple page load, even though the initial navigation behavior is effectively the same.

27. How do you perform mouse actions like hover or drag-and-drop in Selenium?

The Actions class handles complex user interactions that go beyond simple clicks, including moveToElement() for hovering, dragAndDrop() for drag-and-drop interactions, and clickAndHold() combined with moveByOffset() and release() for more granular custom drag sequences.

28. What is cross-browser testing, and how does Selenium support it?

Cross-browser testing verifies that a web application behaves correctly across different browsers and browser versions. Selenium supports this natively by allowing you to instantiate a WebDriver session against any supported browser (Chrome, Firefox, Edge, Safari) using the same test code, simply by swapping which driver you initialize.

29. What is headless browser testing?

Headless testing runs a browser without rendering a visible UI, which speeds up execution and reduces resource usage, making it especially common in CI/CD pipelines where tests run on servers without a display. Chrome and Firefox both support headless modes directly through WebDriver capability options.

30. How do you handle exceptions in Selenium tests?

Beyond standard try-catch blocks, Selenium-specific exceptions like NoSuchElementException, StaleElementReferenceException, and TimeoutException are common enough that experienced testers build retry logic or custom wait conditions specifically around them, rather than treating every exception generically. Understanding which exception a given failure throws is often the fastest way to diagnose whether a test failure is a real bug or a flaky locator issue.

Advanced-Level Selenium Interview Questions (Selenium 4 and Architecture)

31. What changed architecturally between Selenium 3 and Selenium 4?

Selenium 4 made WebDriver fully W3C-compliant, removing the JSON Wire Protocol translation layer that Selenium 3 relied on, which reduces communication overhead and inconsistency between different browser drivers. It also introduced relative locators, native Chrome DevTools Protocol support, a redesigned Grid architecture, and Selenium Manager for automatic driver management.

32. What is the Chrome DevTools Protocol (CDP), and how does Selenium 4 use it?

CDP is a protocol that gives deep, browser-level control beyond standard WebDriver commands, including network request interception, geolocation emulation, JavaScript console log capture, and performance metrics. Selenium 4 added native CDP support, letting testers access these capabilities directly without needing a separate library, though CDP access is Chromium-specific and doesn’t work identically across all browsers.

33. What is WebDriver BiDi, and why was it introduced?

WebDriver BiDi (bidirectional) is a newer, W3C-standardized protocol designed to replace Chromium-only CDP usage with a cross-browser equivalent. It enables the same kinds of capabilities CDP offered, like network interception and console log monitoring, but works consistently across Chrome, Firefox, and other supporting browsers, rather than being locked to Chromium’s DevTools implementation. This matters because CDP-based scripts historically broke whenever Chrome updated its DevTools version, and never worked on Firefox at all.

34. What is Selenium Grid 4, and how is it different from Grid 3?

Selenium Grid 4 was rebuilt with a more scalable, container-friendly architecture, supporting Docker-based deployment and observability through tools like OpenTelemetry. Unlike Grid 3’s hub-and-node model, which could become a bottleneck at scale, Grid 4’s architecture is designed to distribute more cleanly across modern cloud and container infrastructure.

35. How does parallel test execution work in Selenium with TestNG?

TestNG supports parallel execution at the method, class, or suite level, configured through the testng.xml file. Combined with ThreadLocal WebDriver instances (ensuring each thread gets its own isolated driver rather than sharing one across threads), this allows large test suites to run significantly faster by executing multiple tests concurrently rather than sequentially.

36. Why is ThreadLocal important when running Selenium tests in parallel?

Without ThreadLocal, a shared WebDriver instance across parallel threads causes tests to interfere with each other unpredictably, since multiple threads would be issuing commands to the same browser session simultaneously. ThreadLocal<WebDriver> gives each thread its own isolated driver instance, which is essential for reliable parallel execution.

37. How do you integrate Selenium tests into a CI/CD pipeline?

Selenium tests are typically triggered as a build step in tools like Jenkins, GitHub Actions, or GitLab CI, often running against a Selenium Grid or cloud-based browser farm (like BrowserStack or LambdaTest) rather than local browsers, with test results published in a standard reporting format (like JUnit XML) that the CI tool can parse and display.

38. What is flaky test behavior, and how do you reduce it in a Selenium suite?

A flaky test passes and fails inconsistently without any actual code changes, usually caused by timing issues, unstable locators, shared test state, or environment differences. Reducing flakiness generally involves replacing implicit waits and sleeps with proper explicit waits, avoiding brittle locators tied to exact DOM structure, and ensuring tests don’t depend on execution order or shared mutable state.

39. How would you design a Selenium framework from scratch for a new project?

A solid answer walks through the key architectural decisions: Page Object Model for maintainability, a base test class handling driver setup and teardown, a configuration layer for environment-specific settings (URLs, credentials, browser choice), a reporting integration (like Extent Reports or Allure), and a CI pipeline trigger. Interviewers at senior levels care far more about this kind of architectural reasoning than about recalling individual API methods.

40. What’s the difference between hard assertions and soft assertions?

A hard assertion (standard assert in TestNG or JUnit) stops test execution immediately on failure. A soft assertion collects failures without stopping the test, only reporting them together when assertAll() is called at the end, which is useful when you want to verify multiple independent conditions on a page and see all failures in one run rather than fixing them one at a time across multiple executions.

Selenium vs. Playwright and Cypress: What to Say in 2026

41. How does Selenium compare to Playwright in 2026?

Playwright generally offers faster execution, more reliable auto-waiting behavior out of the box, and a more modern API, and it’s become the default choice for many new SDET projects starting from scratch. Selenium remains dominant where an organization already has significant investment in Java, TestNG, and Grid infrastructure, and its broader browser and language support still gives it an edge for certain legacy or highly regulated environments. A strong interview answer articulates this trade-off rather than declaring one tool universally better.

42. How does Selenium compare to Cypress?

Cypress runs directly inside the browser rather than communicating through an external driver protocol, which gives it excellent debugging capabilities and speed for JavaScript-heavy single-page applications, but it historically has had more limited cross-browser and multi-tab support compared to Selenium. Selenium’s browser-agnostic, external-driver architecture makes it more suitable for genuinely broad cross-browser regression suites.

43. If you were starting a new automation project today, would you choose Selenium?

This is a judgment question interviewers use to see whether you think in trade-offs. A reasonable answer: it depends on the team’s existing skills and infrastructure. If the team is already deep in Java and TestNG with an existing Grid setup, extending Selenium often makes more practical sense than a costly migration. For a genuinely greenfield project with no legacy investment, many experienced testers would lean toward Playwright specifically for its faster execution and more modern developer experience.

44. What is Appium’s relationship to Selenium?

Appium extends WebDriver protocol concepts to mobile app automation (iOS and Android), and testers with strong Selenium and WebDriver fundamentals typically ramp up on Appium faster than someone starting mobile automation from scratch, since much of the underlying architecture and locator philosophy carries over directly.

45. How is AI changing Selenium-based test automation in 2026?

AI-assisted tools are increasingly used to generate initial locator strategies, suggest self-healing locators that adapt when the DOM changes slightly, and help identify likely causes of flaky failures from log patterns. These tools speed up framework maintenance, but they don’t replace the underlying understanding of WebDriver architecture and wait strategy that interviews still test directly.

46. What is self-healing test automation, and is it relevant to Selenium?

Self-healing frameworks attempt to automatically adjust a locator when the original one breaks, using AI or heuristic matching to find the most likely replacement element. Several commercial and open-source tools now layer this capability on top of standard Selenium, though most experienced teams still treat it as a supplement to well-written locators, not a substitute for them.

Rapid-Fire Selenium Interview Questions

47. What is the difference between getWindowHandle() and getWindowHandles()?

getWindowHandle() returns the identifier of the current window as a single string. getWindowHandles() returns the identifiers of all open windows in the session as a set.

48. Can Selenium interact with Shadow DOM elements?

Yes, Selenium 4 added native support for accessing Shadow DOM elements through the getShadowRoot() method, which was a common pain point in earlier versions that often required JavaScript workarounds.

49. What is the purpose of driver.manage().window().maximize()?

It maximizes the browser window, which matters because some elements or layouts behave differently (or aren’t visible at all) at smaller viewport sizes, making window size a common source of inconsistent test behavior if left unset.

50. What does getPageSource() return?

It returns the full HTML source of the currently loaded page as a string, occasionally used for debugging or for verifying that specific content exists on the page when a more targeted locator-based check isn’t practical.

51. What is the difference between sendKeys() and JavaScript-based text input?

sendKeys() simulates real keyboard input, triggering the same browser events a genuine user interaction would. JavaScript-based input (executing a script to set a field’s value directly) can bypass those events entirely, which sometimes causes JavaScript-dependent validation on the page to not fire correctly, making sendKeys() the generally safer default.

52. How do you scroll to an element in Selenium?

The most common approach executes JavaScript directly through JavascriptExecutor, calling something like scrollIntoView() on the target element, since WebDriver doesn’t provide a dedicated native scroll method.

53. What is the difference between isDisplayed(), isEnabled(), and isSelected()?

isDisplayed() checks whether an element is visible on the page. isEnabled() checks whether an element can be interacted with (not disabled). isSelected() checks whether a checkbox, radio button, or option is currently selected.

54. What is an assertion library, and do you need one beyond TestNG or JUnit?

Assertion libraries like AssertJ or Hamcrest provide more expressive, readable assertion syntax than the built-in assertions in TestNG or JUnit alone. They’re not strictly required, but many teams adopt them for clearer failure messages and more fluent, chainable assertion syntax.

55. What is the difference between a smoke test suite and a full regression suite in Selenium?

A smoke suite covers a small set of critical, high-priority flows meant to run quickly and catch major breakages early, often on every build. A full regression suite covers a much broader range of scenarios and typically runs less frequently, given its longer execution time.

56. What does WebDriverWait combined with ExpectedConditions actually do?

It polls the DOM repeatedly until a specified condition becomes true (such as elementToBeClickable or visibilityOfElementLocated) or a timeout is reached, forming the standard pattern for reliable explicit waits in Selenium.

57. How do you verify a file download completed successfully in a Selenium test?

Since WebDriver doesn’t directly interact with a browser’s native file download dialog, verification is typically handled by checking the file system directly for the expected file after triggering the download, often combined with a wait loop or polling check for the file’s existence.

58. What is the difference between a test case and a test scenario in the context of automation?

A test scenario describes a broader situation to be validated (such as “user can log in”), while a test case is a specific, detailed set of steps and expected results implementing that scenario, often with multiple test cases covering different data variations of the same scenario.

59. Why do interviewers ask you to walk through your framework rather than just list API methods?

Because framework design and reliability decisions are what actually separate a strong automation engineer from someone who’s memorized a syntax reference. A candidate who can clearly explain their POM structure, wait strategy, and CI integration in a few minutes demonstrates real hands-on judgment that API trivia alone doesn’t reveal.

60. What’s a realistic way to prepare for a Selenium interview in a few weeks?

Build a small real framework against a public demo site (never production credentials), implementing Page Object Model, explicit waits, TestNG data-driven tests, and a basic CI pipeline trigger. Being able to describe a project you actually built, including mistakes you ran into along the way, consistently lands better than reciting memorized definitions.

How to Prepare Beyond Memorizing Answers

Selenium interviews reward candidates who understand the reasoning behind a choice, not just the syntax. If a question asks about explicit versus implicit waits, the strongest answers explain why mixing them causes problems, not just what each one does in isolation.

Since Selenium in Java remains the dominant combination in enterprise QA and SDET interviews, a solid foundation in Java is worth prioritizing if it isn’t already solid, particularly object-oriented concepts and collections, both of which come up constantly in framework design discussions. If you’re coming from a Python background instead, our Python training covers the same fundamentals that transfer directly to Selenium’s Python bindings.

Conclusion

Selenium interviews in 2026 sit at an interesting point: the tool itself has been modernized significantly through Selenium 4’s W3C compliance, relative locators, native DevTools access, and the newer BiDi protocol, while the fundamentals that have always mattered (stable locators, proper waits, clean framework design) remain exactly as important as ever. The candidates who stand out aren’t the ones who’ve memorized the most method signatures. They’re the ones who can explain why they made specific framework decisions, discuss Selenium’s trade-offs against tools like Playwright honestly, and walk through a real project with genuine confidence.

Work through these 60 questions until you can answer each one in your own words, then build a small real framework to back that knowledge up with something concrete you can describe in an interview. That combination, solid conceptual understanding paired with a project you actually built, is what consistently separates candidates who pass Selenium interviews from those who don’t.