Selenium Automation Interview Questions (2026): WebDriver to Frameworks

WebDriver talks to the browser directly, through each browser's native automation API, or through the W3C WebDriver protocol layered on top of that. Selenium RC, the tool WebDriver replaced, injected a JavaScript layer into the page and routed everything through a separate server process, which was slower and fought constantly with the browser's same-origin policy.

RC has been deprecated since Selenium 3. Nobody should be shipping it in a 2026 codebase. Interviewers still ask this to check whether a candidate understands why the architecture changed, not because anyone expects you to have touched RC.

Functionally, almost nothing. Both load a URL and wait for the page load event to fire. navigate() is part of a larger interface that also exposes back(), forward(), and refresh(), so it reads as browser-history navigation, while get() is a simpler one-shot call.

Under the hood, get() actually calls navigate().to() internally, so there's no real performance difference between them. Interviewers ask this to see if you know the interface exists at all, not because your test would behave any differently either way.

id, name, className, tagName, linkText, partialLinkText, cssSelector, and xpath, roughly in that order of preference. ID is fastest and most stable when the app actually assigns a meaningful one. CSS selectors are usually the next-best choice because the browser parses them natively and they stay readable. XPath is the fallback for what CSS genuinely can't express.

An implicit wait is one global timeout, set once per driver session, that applies to every findElement call for the life of that session. It tells WebDriver to poll for up to N seconds before throwing NoSuchElementException. An explicit wait is scoped to one specific condition: WebDriverWait paired with ExpectedConditions polls until a particular thing happens, an element becomes clickable, some text appears, or the timeout hits, whichever comes first.

driver.switchTo().frame() accepts an index, a name or ID string, or a WebElement reference, and the WebElement version is the most reliable since names and indices can shift between builds. To return, driver.switchTo().defaultContent() jumps back to the main document, or parentFrame() if you're nested several frames deep and only need to pop up one level.

driver.switchTo().alert() returns an Alert object. Call .accept() for OK, .dismiss() for Cancel, .getText() to read the message, and .sendKeys() if it's a prompt() with an input field. A native browser alert isn't part of the DOM at all, so normal element locators can't touch it, this dedicated interface is the only path in.

POM wraps each page, or major component, of the application in a class that exposes its elements as fields and its user actions as methods. Test code calls loginPage.login("user", "pass") instead of repeating four findElement calls and a click chain in every single test that touches login.

The payoff shows up when the UI changes. You fix one locator in one class instead of hunting through dozens of test files that all copy-pasted the same broken selector.

@BeforeSuite, @BeforeTest, @BeforeClass, and @BeforeMethod run, in that nesting order, before each @Test method, and the matching @After annotations unwind in reverse. @BeforeMethod fires before every single @Test in the class. @BeforeClass fires once per class, no matter how many @Test methods the class has. Mixing those two up is probably the single most common TestNG mistake that shows up in code review.

NoSuchElementException means findElement searched and the element genuinely isn't in the DOM at that moment, thrown immediately, or after the implicit wait expires, with no further waiting involved. TimeoutException comes from an explicit wait whose condition never became true within the configured duration. It's the "I waited the full 15 seconds and it still didn't happen" exception, distinct from "it's just not there at all."

findElement() returns the first matching WebElement and throws NoSuchElementException the moment nothing matches. findElements() returns a List of WebElements, and if nothing matches you just get an empty list back, no exception at all.

That difference matters for how you write existence checks. A common junior habit is calling findElements(locator).size() greater than 0 to check if something exists, then immediately calling findElement() again right after to actually grab it. That's two DOM queries for one check. Store the list once, check its size, and if it's non-empty just pull index zero from the same list instead of querying twice.

JavascriptExecutor is the WebDriver interface that lets you run arbitrary JavaScript inside the current page's context and get a value back. You cast the driver to it and call executeScript() with a script string and optional arguments.

JavascriptExecutor js = (JavascriptExecutor) driver;
js.executeScript("arguments[0].click();", element);
Object title = js.executeScript("return document.title;");

You reach for it when a normal WebDriver action can't do the job cleanly: forcing a click on an element that's technically covered by something else, reading a value out of a JS variable the page doesn't render to the DOM, or scrolling. It's also an escape hatch when a genuine bug in the site (an invisible overlay, a mistimed animation) is blocking a real click, but be careful, a JS click can succeed even when a real user's mouse click would fail, so overusing it can hide actual UI bugs from your tests.

Headless means the browser runs with no visible window, no GPU-rendered UI you can watch, just the rendering engine executing in memory. It's faster to spin up and uses less memory per instance, which is why almost every CI pipeline runs Selenium headless by default.

ChromeOptions options = new ChromeOptions();
options.addArguments("--headless=new", "--window-size=1920,1080");
WebDriver driver = new ChromeDriver(options);

Always set an explicit window size when running headless. Chrome's default headless viewport is smaller than a typical headed window, and that difference alone can shift where responsive elements land or trigger a different CSS breakpoint, which then breaks locators that worked fine on your local headed run.

WebDriver implements the TakesScreenshot interface, so you cast the driver and call getScreenshotAs(OutputType.FILE), then copy that temp file to wherever you want it saved.

File src = ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE);
FileUtils.copyFile(src, new File("screenshots/" + testName + ".png"));

The useful place to wire this in is a TestNG @AfterMethod that checks ITestResult.getStatus() and only saves a screenshot on ITestResult.FAILURE, so you're not littering disk with a screenshot of every passing test. Attach that file path to your report (Extent, Allure) so a failure is visible without anyone re-running the suite locally to see what actually happened.

driver.manage().getCookies() returns the full cookie set for the current page, getCookieNamed(name) returns one, addCookie(new Cookie(name, value)) sets one, and deleteCookie() or deleteAllCookies() removes them.

The gotcha is that a cookie is scoped to a domain, and Selenium's addCookie() call will throw if you try to set one before navigating to that domain first. A common pattern is to skip a slow UI login by driver.get()-ing the target site once, adding a pre-obtained session cookie, then refreshing the page, which lands you logged in without ever touching the login form. It only works if the session cookie itself is still valid server-side, so this approach breaks silently if your test data setup issues a stale token.

close() closes only the current browser window or tab. If that was the last window open, the WebDriver session ends as a side effect, but if other windows are still open, the session and the driver process stay alive.

quit() closes every window associated with that session and ends the WebDriver session outright, which also terminates the underlying driver executable (chromedriver, geckodriver) and the browser process itself. If a test opens multiple windows and you only ever call close() at the end instead of quit(), you leave orphaned browser and driver processes running on whatever machine executed the test. Do that across a few hundred CI runs and you'll eventually watch a build agent run out of memory for reasons nobody can explain from the test logs alone.

Four pieces are involved: your test script calling the WebDriver client API, the W3C WebDriver protocol (JSON over HTTP), the browser driver executable (chromedriver, geckodriver), and the browser itself. Calling click() sends an HTTP request from the client binding to the driver's local server, the driver translates that into the browser's native automation commands, executes it, and returns the result as an HTTP response.

Selenium 4 dropped the older JSON Wire Protocol translation step for most browsers, since Chrome, Firefox, and Edge had already implemented the W3C spec natively by then. That cut out a whole translation layer and quietly fixed a batch of flaky-command bugs that had nothing to do with anyone's test code.

Actions handles multi-step gestures a single WebElement method can't express on its own: mouse hover, drag and drop, right-click (context click), holding a modifier key while clicking, or click-and-hold sequences. You chain steps like moveToElement(), clickAndHold(), and moveByOffset(), then call .build().perform() once to fire the whole sequence at once.

The common trap is reaching for Actions when a plain .click() would've worked fine, which just adds moving parts for no reason. Save it for gestures a single interaction genuinely can't do. Hover-to-reveal navigation menus are the case that comes up most in real applications.

XPath can traverse upward in the DOM, selecting a parent or ancestor of an element you've matched, and it can match on visible text content. CSS selectors can't do either natively. The "XPath is slower" claim is mostly leftover folklore from older IE-era browsers; in modern Chromium and Firefox both use native DOM query engines, and the real-world speed gap is negligible.

What actually costs you with XPath is maintainability, not speed. A long absolute path like /html/body/div[3]/div/table/tr[2]/td[1] breaks the instant a developer wraps the table in a new div. That's the real objection, and it's the one worth raising in an interview instead of the outdated speed argument.

Relative locators, withTagName("button").above(el), .below(el), .toLeftOf(el), .toRightOf(el), and .near(el), find an element by its rendered position relative to another element you can already locate reliably. They're genuinely useful on forms where a label has a stable ID but the input sitting next to it doesn't, which happens constantly in auto-generated admin panels.

The catch: they're calculated from rendered coordinates, so a responsive layout change, a hidden element, or a reflow can silently break one without any error until the test runs against the new layout. This is a comparatively recent feature (Selenium 4, first released in 2021), and interviewers sometimes ask about it specifically to check whether you've kept up with the framework at all.

Stop matching the whole ID and match the stable prefix instead. A CSS attribute-contains selector like [id^='user-row-'], or an XPath using contains(@id, 'user-row-'), both work off the fixed part and ignore the random suffix.

The more durable fix, if you can influence the app, is asking the dev team to add a data-testid attribute that never changes. Interviews usually just want the CSS or XPath workaround, but naming the better long-term fix unprompted is what separates a strong answer from an adequate one.

WebDriverWait is really a simpler, preset case of FluentWait. FluentWait lets you configure the polling interval directly and choose which exceptions to ignore mid-poll, instead of accepting the library defaults. You'd reach for it when an element's momentary absence should be tolerated during polling, a loading spinner that briefly detaches and reattaches to the DOM, say, where a plain WebDriverWait would blow up on a transient StaleElementReferenceException instead of continuing to poll through it.

Wait<WebDriver> wait = new FluentWait<>(driver)
    .withTimeout(Duration.ofSeconds(20))
    .pollingEvery(Duration.ofMillis(500))
    .ignoring(NoSuchElementException.class, StaleElementReferenceException.class);

WebElement submitButton = wait.until(
    driver -> driver.findElement(By.id("submit-btn"))
);

driver.getWindowHandles() returns the set of every open window and tab handle. Store the original handle before triggering whatever opens the new tab, iterate the updated set, and switch to whichever handle isn't the one you started with, using driver.switchTo().window(newHandle).

Handles are opaque strings with no guaranteed order, so assuming "index 1 is always the new tab" is a common bug. Diff the before-and-after handle sets instead of trusting position.

Wrap the WebElement in Selenium's Select class, which gives you selectByVisibleText(), selectByValue(), and selectByIndex() instead of manually clicking the dropdown open and clicking an option. For a multi-select, deselectAll() and getAllSelectedOptions() are also available.

The Select class only works against a genuine <select> element. Plenty of modern UI kits render a fake dropdown out of styled divs and spans, and Select throws UnexpectedTagNameException against those. You're back to plain clicks and visible-text matching in that case.

@FindBy declares how to locate a field, @FindBy(id = "username"), without you calling findElement yourself. PageFactory.initElements(driver, this) then reflects over the class, reads those annotations, and builds lazy-initialized proxy objects for each WebElement field.

"Lazy" is the key word. The actual findElement call doesn't fire until you first interact with the element, not the moment the page object gets constructed, which matters for elements that don't exist on the page yet at construction time.

A regular Assert.assertEquals() throws immediately on failure and the test method stops right there. SoftAssert collects every failure without stopping execution, and you call assertAll() at the end to report everything that failed in one pass.

Pick SoftAssert when one test method checks several independent things on a page, five field values after a form submit, say, and you want the full failure report in a single run instead of fixing one assertion, rerunning, hitting the next failure, fixing that, and rerunning again.

@DataProvider marks a method that returns an Object[][] (or an Iterator), and TestNG runs the annotated test once per row, feeding each row's values in as parameters. That's how you get data-driven testing without writing a separate loop inside the test body, and it's the mechanism TestNG's own documentation describes as the standard way to parameterize a test across multiple data sets (TestNG documentation).

An XML suite parameter, <parameter name="browser" value="chrome"/>, is simpler and static: one value per run, useful for environment config like browser or base URL, not for iterating a dataset.

@DataProvider(name = "loginData")
public Object[][] loginData() {
    return new Object[][] {
        {"user1", "pass123", true},
        {"user2", "wrongpass", false},
        {"", "pass123", false}
    };
}

@Test(dataProvider = "loginData")
public void testLogin(String username, String password, boolean expected) {
    LoginPage loginPage = new LoginPage(driver);
    loginPage.login(username, password);
    Assert.assertEquals(loginPage.isLoginSuccessful(), expected);
}

A data-driven framework separates test data from test logic, the DataProvider example above is data-driven in miniature, so the same test method runs repeatedly against different rows pulled from a CSV, an Excel file, or a database. A keyword-driven framework goes further and separates the actions themselves into a table (Click, Type, Verify) that non-programmers can author, with an engine that interprets each keyword row and calls the matching Selenium method underneath.

Hybrid frameworks combine both: keywords for the action vocabulary, external data for the values, POM underneath for element management. That's what most mature enterprise Selenium suites actually run once the test count passes a few hundred and one person can no longer hold the whole thing in their head.

Cucumber lets you write scenarios in Gherkin (Given/When/Then, close to plain English) that business stakeholders can read and sign off on without touching code. Step definitions are the Java methods that map each Gherkin line to actual Selenium calls, so "When the user logs in with valid credentials" becomes a method annotated @When("the user logs in with valid credentials") that calls loginPage.login() underneath.

The honest tradeoff interviewers want named: BDD adds a real maintenance layer, feature files, step definitions, and the mapping between them, for teams that don't actually have non-technical stakeholders reading the scenarios. I've seen more of those wasted-effort setups than genuinely collaborative ones, which isn't the answer most BDD advocates want to hear.

The exception fires when the DOM node your WebElement points to has been removed or replaced, most often because part of the page re-rendered, a React state update or an AJAX refresh, after you located the element but before you interacted with it. "Re-locate it" is the right instinct, but the reliable version wraps the interaction in a small retry loop, or a FluentWait ignoring that specific exception, since a single re-locate can itself land mid-re-render and go stale again.

Before Selenium 4.6, you had to manually download the right chromedriver or geckodriver version, match it to your installed browser version, and either set it on the system PATH or point to it with a system property like webdriver.chrome.driver. Most teams offloaded that to a third-party library, usually WebDriverManager by Boni Garcia, which detected the installed browser and pulled the matching driver automatically.

Selenium 4.6 folded that capability directly into Selenium itself as Selenium Manager, a small binary bundled with the language bindings that runs before your test starts, detects the installed browser and its version, and resolves or downloads a matching driver without you writing any setup code at all. You can still set webdriver.chrome.driver manually if you want to pin an exact driver version.

The failure mode to watch for is browser auto-update. If Chrome silently updates itself to a new major version mid-CI-run while Selenium Manager's cached driver mapping is stale, you get a driver-to-browser version mismatch error that looks like a Selenium bug but is really an environment drift problem. Pinning both browser and driver versions in your CI base image avoids it entirely.

You don't click the button that opens the picker at all. If the upload control is backed by a genuine input element with type set to file, you can call sendKeys() on that input directly with the absolute file path, and the browser accepts the file without ever opening the native OS dialog.

WebElement upload = driver.findElement(By.id("resume-upload"));
upload.sendKeys("/Users/qa/testdata/resume.pdf");

The trick only breaks down when the real input is hidden with something like display none or visibility hidden to let a styled button sit on top of it, because W3C interactability rules reject sendKeys on an element the driver considers not visible. In that case, use JavascriptExecutor to briefly strip the hiding style, or set the value directly through the DOM and dispatch a change event, then continue with the rest of the flow as normal.

First you have to make Chrome download to a predictable folder without prompting, which you set through ChromeOptions preferences rather than anything in the DOM.

Map<String, Object> prefs = new HashMap<>();
prefs.put("download.default_directory", "/tmp/downloads");
prefs.put("download.prompt_for_download", false);
options.setExperimentalOption("prefs", prefs);

Checking for existence right after the click is where tests get flaky, because a large file is still mid-write as a temporary file with a suffix like .crdownload, and File.exists() on the final filename can return true before the bytes finish landing. The reliable check is a small poll loop: wait for a file with the expected extension to appear, then confirm its size has stopped changing across two checks a second or two apart, or simply confirm the .crdownload temp file is gone, since Chrome renames it to the final name only once the write completes.

Actions.dragAndDrop(), or the manual clickAndHold, moveToElement, release sequence, simulates native mouse events, mousedown, mousemove, mouseup, at roughly the pointer level. Plenty of modern drag-and-drop libraries don't listen for those at all. They bind to the HTML5 drag events, dragstart, dragenter, dragover, drop, which carry their own DataTransfer object, and WebDriver's synthetic mouse movement never fires those events because it's simulating a different input model entirely.

The fix is to fire the events the library actually listens for. Build a small JavaScript helper that constructs a DragEvent with a DataTransfer payload and dispatches dragstart on the source element, then dragenter, dragover, and drop on the target in sequence, calling it through JavascriptExecutor. There's no single universal snippet that works everywhere, since some libraries use HTML5 drag events, others use pointer events with their own gesture detection, so the first debugging step is always opening devtools and checking which event listener actually reacts when a real mouse drags the element.

scrollIntoView(true), or its equivalent block: 'start' option, aligns the target element to the top edge of the viewport. On a page with a fixed or sticky header, the top edge of the viewport is exactly where that header sits, so the element you scrolled to ends up hidden underneath it, and the click gets blocked or lands on the header instead.

arguments[0].scrollIntoView({block: "center", inline: "nearest"});

Passing block: 'center' instead scrolls the element to the vertical middle of the viewport, clear of a header pinned to the top. If you need block: 'start' for another reason, an alternative is scrolling normally and then nudging the window up afterward with window.scrollBy(0, -headerHeightInPixels) so the header's own height gets accounted for. Some sites already solve this with a scroll-padding-top CSS rule on the html element, in which case a plain scrollIntoView call respects that padding automatically and you don't need any of this.

A shadow root is a separate DOM subtree attached to a host element through element.attachShadow(), and ordinary CSS or XPath locators can't cross that boundary because the shadow tree isn't part of the main document tree those locators search.

WebElement host = driver.findElement(By.cssSelector("my-custom-widget"));
SearchContext shadowRoot = host.getShadowRoot();
WebElement inner = shadowRoot.findElement(By.cssSelector(".label"));

Selenium 4 exposes getShadowRoot() directly on WebElement, but only for open shadow roots. A closed shadow root is inaccessible to Selenium the same way it's inaccessible to plain JavaScript, since the browser itself doesn't expose a reference to it, and no automation tool including CDP-based ones can reach inside a genuinely closed one. Before Selenium 4 added native support, people did the same thing purely through JavascriptExecutor calling element.shadowRoot.querySelector() and returning the resulting element reference, which is still a reasonable fallback for deeply nested shadow trees, like a component inside another component inside a design system wrapper.

Almost always it's a WebDriver reference declared as a shared static or instance field being read and written by multiple threads at once. TestNG's parallel execution spins up several threads, and if they all touch the same driver variable, one thread's setup can overwrite another thread's reference mid-test, so a test on thread A ends up issuing commands against the browser thread B just created.

private static ThreadLocal<WebDriver> driver = new ThreadLocal<>();

@BeforeMethod
public void setUp() {
    driver.set(new ChromeDriver());
}

@AfterMethod
public void tearDown() {
    driver.get().quit();
    driver.remove();
}

Wrapping the driver in ThreadLocal gives each thread its own isolated reference, so threads can never see or mutate each other's browser instance. Also double check the parallel attribute in your testng.xml, methods versus classes versus tests changes the granularity at which new threads spin up, and if you set parallel="methods" you need the ThreadLocal initialized fresh per test method, not just once per class instance.

Each browser has its own Options class, ChromeOptions, FirefoxOptions, EdgeOptions, all implementing MutableCapabilities. A handful of capabilities are shared across all of them, browserName and platformName for instance, but most of the flags that actually control browser behavior are vendor-specific and don't transfer.

Disabling the notification permission prompt in Chrome is a Chrome preference, set through setExperimentalOption with a prefs map containing profile.default_content_setting_values.notifications set to 2. Firefox does the equivalent thing through a completely different mechanism, FirefoxProfile.setPreference with dom.webnotifications.enabled set to false. A common mistake on multi-browser frameworks is building one shared capabilities object and passing Chrome-specific arguments into FirefoxOptions, which Selenium and the browser driver just silently ignore rather than erroring on, so the test suite runs and passes while the notification popup you thought you suppressed is still showing up in Firefox and just never got clicked on, or got clicked on by luck through a broad wait timeout.

Locate the table, get all the row elements inside its body, and loop through them, pulling the cell elements for each row as you go.

List<WebElement> rows = driver.findElements(By.cssSelector("table#orders tbody tr"));
for (WebElement row : rows) {
    List<WebElement> cells = row.findElements(By.tagName("td"));
    if (cells.get(0).getText().equals("ORD-12345")) {
        assertThat(cells.get(2).getText()).isEqualTo("Shipped");
    }
}

Avoid hardcoding a fixed row index like row three to find your record, since sort order, pagination, and inserted test data from other tests can shift exactly where a given row lands, which is a classic source of flaky table assertions. For a single lookup, a more direct XPath skips the manual loop entirely: //tr[td[contains(text(),'ORD-12345')]], which returns the whole matching row in one call and cuts your locator round trips roughly in half.

TestNG exposes an IRetryAnalyzer interface with one method, retry(ITestResult), that you implement to return true up to some maximum attempt count you track yourself with a counter field. You can attach it to a single test through the retryAnalyzer attribute on @Test, but the more practical setup wires it in globally through an IAnnotationTransformer that injects the retry analyzer onto every test method automatically, so nobody on the team has to remember to add it by hand to a new test class.

The part teams miss is that retries by themselves just paper over instability if you don't also track which tests needed a retry and how often. A test that only passes on its second attempt every single run isn't stable, it's failing consistently and getting bailed out by the retry logic. That data needs to feed back into an actual investigation, usually a missing explicit wait or a race condition in test setup, rather than becoming a permanent workaround that quietly hides a real bug from the team.

The native OS-level basic auth prompt isn't part of the page's DOM, so no Selenium locator can see it or interact with it. The simplest workaround is embedding credentials directly in the URL, https://username:password@hostname/path, which Chrome and Firefox both accept and will use to satisfy the prompt without ever displaying it. It only covers Basic and Digest auth, not SSO or OAuth flows, since those need an actual form to be submitted somewhere.

On Chrome, Selenium 4 also gives you a network-level path through CDP: enabling the Fetch or Network domain and intercepting the auth challenge to supply credentials programmatically before the page even renders the prompt. It's more setup than the URL trick, but it's the option to reach for on sites that specifically block credentials embedded in the URL for security reasons, since some servers now reject that format outright.

Selenium's own documentation calls this out directly: mixing the two can produce unpredictable, longer-than-expected wait times, because both timers can effectively stack (Selenium's waiting-strategies docs). The textbook example, and the one from this page's opening scene, is a 10-second implicit wait combined with a 15-second explicit wait producing something closer to 20 seconds in the worst case, not 15, because the driver keeps re-polling under the implicit wait's rules while the explicit wait is separately counting down.

The safe pattern most teams settle on: pick one strategy globally, usually explicit waits (with FluentWait for the handful of genuinely flaky elements), and set the implicit wait to zero everywhere else. Not both. Ever.

PageFactory's proxy elements cache the underlying WebElement after first use by default. That's a real problem on pages with dynamic content: if the element gets removed and re-rendered, a common React or Angular pattern, the cached reference goes stale and throws StaleElementReferenceException on the next interaction. Most teams either re-run initElements() at the top of each test method or skip field caching entirely and call findElement inside plain methods instead.

For parallel runs, the bigger risk is Page Objects unintentionally sharing one WebDriver instance across threads. The standard fix is a ThreadLocal<WebDriver>, with each Page Object constructor pulling the driver for its own thread rather than reading from a shared static field.

public class LoginPage {
    private WebDriver driver;

    @FindBy(id = "username")
    private WebElement usernameField;

    @FindBy(id = "password")
    private WebElement passwordField;

    @FindBy(css = "button[type='submit']")
    private WebElement loginButton;

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

    public void login(String username, String password) {
        usernameField.sendKeys(username);
        passwordField.sendKeys(password);
        loginButton.click();
    }
}

Another element, an overlay, a sticky header, a cookie banner, or a spinner still animating out, is sitting visually on top of the element you're trying to click, even though your locator found the right node. The lazy fix everyone reaches for first is a JavaScript executor click, ((JavascriptExecutor) driver).executeScript("arguments[0].click();", element), which bypasses the visibility check entirely. That can mask a real bug where an actual user couldn't click that button either.

The more defensible fix waits for the obstructing element to actually disappear, ExpectedConditions.invisibilityOfElementLocated(), before clicking normally. Not always possible. Usually worth the extra line.

Grid 3 was a simple hub-and-node setup: one hub process accepted incoming session requests and queued them against whatever nodes had registered capacity, and if no node was free the request generally just failed rather than waiting.

Grid 4 breaks that single hub process into separate components: a Router that receives incoming requests and forwards them onward, a Distributor that tracks live capacity across registered Nodes and assigns new sessions to one with room, a Session Map that records which physical Node an active session is running on so every subsequent command for that session gets routed correctly, and a Session Queue that holds new session requests when capacity is temporarily exhausted instead of failing them outright. All of that can run bundled together as a single standalone process for local use, or scaled out as genuinely separate services behind a load balancer for a real production Grid, which the old Grid 3 architecture had no clean way to do since the hub itself was a single point of both routing and bottleneck.

Practically, this means Grid 4 degrades more gracefully under load, queueing requests rather than erroring immediately, and lets you scale the piece that's actually your bottleneck, usually the Distributor or the number of registered Nodes, independently of the rest of the system.

Plain WebDriver only exposes what the W3C spec defines: navigation, element interaction, script execution, cookie and window management. CDP is Chrome's own internal protocol and sits underneath that, giving you access to things WebDriver was never designed to expose.

DevTools devTools = ((HasDevTools) driver).getDevTools();
devTools.createSession();
devTools.send(Network.enable(Optional.empty(), Optional.empty(), Optional.empty()));
devTools.addListener(Network.responseReceived(), response ->
    System.out.println(response.getResponse().getStatus()));

With CDP you can intercept and rewrite network requests and responses, blocking third-party trackers or forcing a 500 to test how the UI handles a real error state, capture the browser's own console.log and console.error output instead of guessing why something failed silently, override geolocation or device metrics for responsive and location-aware testing, throttle the network to simulate a slow connection, and pull real performance timing data off the page. The tradeoff is that CDP is Chromium-specific, so Edge gets it for free since it's Chromium-based, but any framework logic built directly on CDP calls has to be reimplemented or skipped for Firefox and Safari, which is a large part of why the WebDriver BiDi effort exists, to standardize a version of this same capability set across browsers.

In Selenium 3 and earlier, the client bindings spoke Selenium's own JSON Wire Protocol, and browser vendor drivers either had to natively understand that protocol or Selenium had to translate every command into whatever format that specific driver actually expected underneath. Selenium 4 dropped that translation layer entirely and speaks the official W3C WebDriver specification end to end, a spec browser vendors themselves helped author and now implement natively in chromedriver and geckodriver.

The visible fallout landed mostly in capabilities. The old flat DesiredCapabilities map with keys like chromeOptions got replaced by vendor-namespaced capabilities like goog:chromeOptions, and drivers built on the W3C spec reject capabilities they don't recognize in that namespaced format instead of silently accepting whatever you hand them. Teams that had hand-rolled a DesiredCapabilities map from an old Selenium 3 framework and upgraded the client library without updating that code hit driver instantiation failures that looked like Selenium bugs but were really stale capability formats.

The W3C spec also formalizes input actions differently, defining a more precise pointer and keyboard input state model for the Actions class than Selenium's own older simplified implementation used, which occasionally changed the exact timing and coordinates of complex multi-step Actions chains between Selenium 3 and 4. The fix across all of this is migrating fully onto the ChromeOptions and FirefoxOptions builder classes instead of any hand-built capabilities map, since those builders always emit the correct namespaced format for whichever driver version you're targeting.

A canvas is a single DOM element, and everything drawn inside it, bars, lines, shapes, exists only as pixels the browser painted, not as separate nodes Selenium can find with a locator. There is no findElement() call that gets you to the third bar in a chart, because that bar isn't a DOM node at all.

For verifying rendered output, take a screenshot of just the canvas element's bounding box and run pixel or perceptual image comparison against a stored baseline, using a visual regression tool or a simpler pixel-diff library, and accept some tolerance for anti-aliasing and font rendering differences across machines. For verifying interaction, you either calculate the exact pixel coordinates you need to click, based on a chart library's documented data-to-pixel mapping, or reach into the library's own internal state object through JavascriptExecutor if it exposes one globally, then use Actions to click at that calculated point rather than relying on a locator that doesn't exist. If the library renders an accessible SVG or table alongside the canvas for screen readers, which some charting libraries do, testing against that hidden accessible layer instead is far more stable than any coordinate math.

A single standalone Chrome image is fine for running things locally, but a real CI setup typically composes a selenium/hub container alongside one or more node-chrome and node-firefox containers, each pointed at the hub's internal Docker network address through the SE_EVENT_BUS_HOST and SE_EVENT_BUS_PORT environment variables so nodes actually register.

Shared memory size matters more than people expect. Docker's default /dev/shm is tiny, and Chrome under that default crashes with session not created errors or random renderer crashes, so you need either --shm-size=2g on the container or a mounted /dev/shm volume sized properly. For debugging, node images ship a VNC server on port 5900 by default, and turning that on lets you actually watch what a failing test is doing live in the browser instead of reading through logs blind trying to reconstruct what happened.

Node scaling needs planning too, either a fixed replica count per browser type sized to match your parallel thread count, or dynamic node registration if you're autoscaling based on queue depth. And healthchecks matter more than they look like they should, because a node container that's up and running but hasn't finished registering with the hub yet will make Selenium fail with no such session errors if tests start hitting the hub too early, so CI pipelines need an actual wait-for-hub-ready step rather than a fixed sleep that either wastes time or isn't long enough.

CDP is Chrome's own internal protocol, powerful but tied to Chromium, so anything built on top of it, network interception, console log capture, geolocation overrides, works on Chrome and Edge and simply isn't available at all on Firefox or Safari without a completely separate implementation.

WebDriver BiDi is a newer W3C standard, still landing across browsers as implementations mature, that aims to standardize a browser-agnostic version of that same category of capability. The name refers to bidirectional communication: the classic WebDriver protocol is strictly request and response, your client asks a question and the browser answers, while BiDi lets the browser push events to the client on its own, like a console message or a network request firing, without your test polling for it. That covers console log streaming and network interception specified once, the same way, for every vendor to implement, instead of each browser needing its own bespoke integration.

As of right now, Selenium 4 still leans on CDP for Chrome and Edge-specific features and is gradually shifting equivalent functionality onto BiDi as browser support catches up, which means framework code sometimes has to check driver capabilities first to decide which API path to use depending on what the target browser actually implements at that point in time.

If there genuinely is no underlying input element with type file anywhere in the DOM, Selenium fundamentally cannot help you, because WebDriver's entire command surface operates inside the browser's rendering context, not the operating system's own desktop. A native file picker window is outside that boundary entirely, the same way a print dialog or an OS-level download prompt is.

Start by checking devtools more carefully rather than assuming the widget is truly custom. In the large majority of cases there's still a real input element with type file sitting underneath a styled button, just hidden visually, and you can call sendKeys() on it directly once you strip whatever style is making the driver consider it non-interactable, usually through JavascriptExecutor removing a display none or visibility hidden rule first. If the page truly opens the picker through some non-standard mechanism with no input element backing it at all, you're into OS-level automation entirely outside Selenium's scope, tools like AutoIT on Windows or Java's Robot class typing a file path and hitting enter blind, which is fragile because it depends on dialog focus and OS window behavior and simply can't run headless. Some teams sidestep the whole problem by calling the backend upload API directly for test data setup and only using the UI afterward to verify the file shows up, treating the actual native dialog interaction as out of scope for browser automation entirely.

Selenium's WebDriver protocol is a synchronous HTTP request and response protocol between your test process and a separate driver process, chromedriver or geckodriver, which then talks to the actual browser. Every single command, a click, a find, reading text, is a full round trip: serialize the command to JSON, send it over HTTP, the driver parses it and executes it against the browser, then serializes a response back the same way.

Playwright talks to the browser over a persistent WebSocket connection using the browser's own remote debugging protocol directly, with its own driver process bundled into the library rather than a separate binary you manage yourself, which cuts out a layer and lets it batch calls more efficiently instead of paying a full round trip per action. Playwright also bakes actionability checks into every action by default, auto-waiting for an element to be visible, stable, and not obscured before acting on it, where Selenium leaves all of that entirely up to you. A lot of what gets blamed as Selenium flakiness is really a team not writing proper explicit waits, not some fundamental protocol limitation Selenium can't overcome.

Selenium's real advantage is breadth rather than speed. It supports more browser and language combinations across a much longer history, real SafariDriver support, legacy IEDriverServer for enterprise teams still stuck supporting old internal tools, and it sits underneath a much larger existing ecosystem of Grid infrastructure and cloud vendor support like BrowserStack and Sauce Labs. Plenty of large legacy suites simply can't justify the cost of rewriting away from that ecosystem, even knowing Playwright's underlying protocol is architecturally leaner.

Start by ruling out environment differences before touching the test code. CI almost always runs headless while local development often runs headed, and headless Chrome can render fonts, scrollbars, and viewport dimensions slightly differently, which is enough to shift element positions or trip a different CSS breakpoint than the one your local headed run hits. Reproduce headless locally with the exact window size CI uses before assuming the test logic itself is wrong.

CI agents also tend to be resource-constrained compared to a developer laptop, shared CPU, less memory, more noisy neighbors, so real page load and animation timing runs slower there, and that exposes waits that were only ever passing locally because your machine was fast enough to beat the race, not because the wait was actually correct. Capture the browser console log and a screenshot at the exact moment of failure, through the CDP Log domain or driver.manage().logs(), and save both as CI artifacts rather than trusting the stack trace alone to explain what happened.

Check specifically for animation and transition timing next, since a wait for element to be clickable can be satisfied while a CSS transition is still sliding that element toward its final resting position, so a click lands at coordinates the element hasn't reached yet. Also look for test order dependencies or shared test data colliding across parallel workers in CI, something that never surfaces when you run one test at a time locally. If your Grid setup supports it, recording video of the failing run, which most Docker-based Selenium Grid images with VNC enabled do, catches the full sequence leading to failure in a way a single screenshot never can.