Top 50 Selenium with Java Interview Questions and Answers

Detailed explanation

It is well suited to automating web user journeys across supported browsers. It does not provide a test runner, assertions, reporting, or desktop-app automation by itself, so Java projects commonly combine it with TestNG and supporting libraries.

Practical example

A retail team uses WebDriver to verify that a customer can search, add an item, and check out in Chrome and Firefox.

Detailed explanation

The Selenium Java bindings expose interfaces such as WebDriver and WebElement. A local driver service or Selenium Grid receives protocol commands, delegates them to the browser-specific automation implementation, and returns a response; this separation enables cross-browser and remote execution.

Practical example

Calling driver.get(url) through ChromeDriver sends a navigation command to the Chrome driver service, which asks Chrome to load the page.

Detailed explanation

ChromeDriver, GeckoDriver, and EdgeDriver connect Selenium to their respective browsers. Modern Selenium can invoke Selenium Manager automatically, reducing manual executable-path setup, although controlled CI environments may still pin and preinstall browser and driver versions.

Practical example

With a supported Chrome installation, new ChromeDriver() can use Selenium Manager instead of setting webdriver.chrome.driver manually.

Detailed explanation

A driver constructor starts a browser session; the test then navigates and interacts through that session. quit closes every associated window and ends the driver process, while close only closes the current window and may leave the session alive.

Practical example

A TestNG @BeforeMethod creates ChromeDriver and @AfterMethod(alwaysRun = true) calls driver.quit() when the driver is non-null.

Detailed explanation

Prefer unique, stable attributes that express the element's purpose, often an id or dedicated data-test attribute. CSS and XPath are useful for relationships and compound conditions, but a shorter locator is not automatically better if it is unstable or ambiguous.

Practical example

By.cssSelector("[data-testid='submit-order']") targets a test contract without depending on layout classes.

Detailed explanation

CSS selectors are usually readable for IDs, classes, attributes, and parent-to-child relationships. XPath is valuable when locating by normalized visible text or navigating to ancestors and siblings; choose the clearest stable expression rather than relying on assumed performance differences.

Practical example

Use By.cssSelector("form#login button[type='submit']") for structure, or By.xpath("//button[normalize-space()='Sign in']") when stable text is the contract.

Detailed explanation

WebElement operations execute against the current browser session, not a copied Java DOM object. Methods can inspect state with isDisplayed, isEnabled, and isSelected, or search descendants with findElement; the reference can become stale if the DOM replaces the element.

Practical example

A test finds an email input, clears it, sends a value, and checks the value through getAttribute("value").

Detailed explanation

They start with RelativeLocator.with(By) and use browser geometry to filter candidates. They can clarify a layout-based relationship, but stable semantic attributes are usually more resilient when responsive layouts can rearrange elements.

Practical example

A test can locate an input with with(By.tagName("input")).below(By.id("email-label")) when no stronger attribute is available.

Detailed explanation

The org.openqa.selenium.support.ui.Select helper works only with an actual select tag. It can inspect selected options, detect multiple selection, and deselect options for multi-select controls.

Practical example

new Select(driver.findElement(By.id("country"))).selectByVisibleText("Canada") selects the user-facing option.

Detailed explanation

driver.switchTo().alert() returns an Alert for the active modal dialog. Because an unexpected alert can block other commands, an explicit wait for ExpectedConditions.alertIsPresent() is safer when appearance is asynchronous.

Practical example

After deleting an item, wait for alertIsPresent, verify the warning text, and call accept to confirm deletion.

Detailed explanation

Elements inside a frame belong to a different browsing context and cannot be found from the parent context. Waiting with frameToBeAvailableAndSwitchToIt combines availability checking and switching when the frame loads asynchronously.

Practical example

A payment test switches to the hosted card iframe by a stable locator, enters card data, then calls defaultContent before using the checkout page.

Detailed explanation

getWindowHandle returns the current handle and getWindowHandles returns all open handles without guaranteed order. Selenium 4's switchTo().newWindow(WindowType.TAB or WINDOW) creates and switches to a new context; tests should retain known handles and wait for the expected count.

Practical example

Store the original handle, click a link that opens a tab, wait for two handles, switch to the new handle, then close it and return.

Detailed explanation

Actions builds a sequence of low-level input-source actions and sends it when perform is called. It is appropriate when a normal WebElement method cannot express the user gesture, while ordinary click and sendKeys remain simpler for basic interactions.

Practical example

new Actions(driver).moveToElement(menu).click(submenu).perform() opens a hover menu and chooses an item.

Detailed explanation

It can inspect application state, invoke browser-side helpers, or perform targeted diagnostics. JavaScript clicks and direct value changes bypass normal user interaction and may conceal real usability defects, so standard WebDriver operations should be preferred.

Practical example

A diagnostic helper uses executeScript("return document.readyState") to record page state during a timeout.

Detailed explanation

Explicit waits using WebDriverWait and ExpectedConditions usually express application readiness most clearly. Thread.sleep pauses for a fixed time regardless of state, making tests unnecessarily slow or still unreliable, so it should not be the synchronization strategy.

Practical example

Wait until a save button is clickable instead of sleeping for an assumed two seconds after the page opens.

Detailed explanation

Configure it with driver.manage().timeouts().implicitlyWait(Duration). It applies globally to findElement and findElements for that session, not to arbitrary states such as clickability or text changes, and can make absence checks and mixed explicit waits harder to reason about.

Practical example

A five-second implicit wait lets a late-rendered input appear during lookup, but it does not guarantee that the input is enabled.

Detailed explanation

WebDriverWait repeatedly evaluates an ExpectedCondition until it succeeds or times out, ignoring selected transient lookup failures. Conditions should represent the state required by the next action, such as visibility, clickability, URL, text, or a domain-specific predicate.

Practical example

Wait for the checkout button to be clickable, then click the returned element rather than locating it again immediately.

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

Detailed explanation

WebDriverWait is itself a specialization of FluentWait<WebDriver>. A custom FluentWait can poll another object or tolerate a narrowly understood transient exception, but ignored exceptions should not be broad enough to hide genuine defects.

Practical example

A test polls an eventually updated status every 500 milliseconds for 20 seconds while ignoring only NoSuchElementException during rerendering.

Detailed explanation

Choose the weakest condition that still guarantees the next intended operation. Even elementToBeClickable cannot prove that an animation or overlay will not intercept a click, so application-specific readiness may require waiting for that blocker to disappear.

Practical example

Presence is enough to read a hidden attribute, visibility suits displayed text, and clickability suits an enabled submit button.

Detailed explanation

Avoid generated IDs and classes when stable labels, names, ARIA attributes, or test IDs are available. For repeated rows, scope the search to the row identified by stable content or a data key, then locate the action within that row.

Practical example

Find the order row whose data-order-id matches the created order, then locate its cancel button as a descendant.

Detailed explanation

Prefer storing By locators and finding elements when needed, then wait for the expected refreshed state. A bounded retry can be appropriate for a known rerender boundary, but repeatedly catching stale exceptions hides unstable synchronization and cannot repair an incorrect locator.

Practical example

After changing a filter that redraws a results table, wait for stalenessOf the old row and then locate the new row.

Detailed explanation

Because custom widgets are not select tags, model the actual keyboard or pointer behavior and accessibility semantics. Wait for the results container and desired option after entering data, and assert the committed value rather than only the click.

Practical example

Type a unique city name, wait for the role=option element with the expected label, click it, and verify the hidden location ID.

Detailed explanation

WebDriver transfers or assigns the file through the file input without automating the operating-system picker. With RemoteWebDriver, Selenium can use a LocalFileDetector when a local file must be uploaded to a remote node.

Practical example

Resolve a fixture with Path.toAbsolutePath(), send its string path to input[type='file'], and wait for the uploaded filename or server status.

Detailed explanation

Screenshots are most useful as failure evidence when paired with URL, browser, logs, and test data. Store them with collision-safe names and attach them through the reporting layer; a screenshot alone may miss off-screen state or the cause of failure.

Practical example

A TestNG listener captures OutputType.BYTES after a failed test and attaches the bytes to that test's report entry.

Detailed explanation

Browser options can set a deterministic directory for local or containerized runs. Poll the filesystem for the completed artifact rather than sleeping, reject temporary partial files, and parse the document or checksum when content matters; remote Grid downloads may require Selenium's downloadable-files support or node-accessible storage.

Practical example

After exporting orders, wait until exactly one non-temporary CSV appears, then verify its headers and expected order ID.

Detailed explanation

The browser must be on a compatible domain before adding a cookie. Tests can inspect name, value, domain, path, expiry, secure, HttpOnly, and SameSite-related data where supported, but should avoid coupling to internal session formats without a clear purpose.

Practical example

A consent test loads the site, adds a preference cookie for that domain, refreshes, and verifies the banner state.

Detailed explanation

Use hard assertions when continuing would be invalid or misleading. Soft assertions can collect independent observations on one page, but assertAll must be called and each test should use its own SoftAssert instance, especially in parallel runs.

Practical example

A profile test hard-asserts that the page loaded, then soft-asserts name, email, and membership fields before calling assertAll.

Detailed explanation

@BeforeMethod and @AfterMethod commonly isolate a browser per test method, while broader scopes can initialize immutable shared services. Teardown should use alwaysRun = true so resources are released even when setup or the test fails.

Practical example

A base test creates a driver in @BeforeMethod and quits it in @AfterMethod(alwaysRun = true), while @BeforeSuite loads read-only configuration.

Detailed explanation

Data-driven tests are useful when the workflow is the same and only inputs and expected outcomes vary. Datasets should have meaningful labels, remain independently runnable, and avoid producing an unreviewable Cartesian explosion; parallel providers require isolated drivers and test data.

Practical example

A login validation test receives username, password, and expected message for blank, malformed, locked, and valid accounts.

Detailed explanation

The pom.xml declares Selenium and TestNG test dependencies and configures the Maven Surefire Plugin to discover or select suites. Versioned dependencies and a Maven wrapper improve reproducibility, while environment-specific endpoints and secrets should be injected rather than committed.

Practical example

CI runs ./mvnw test with a browser property, and Surefire executes TestNG tests while publishing XML results.

Detailed explanation

A page object should expose meaningful actions and observations, not reproduce every element as public fields. Composition works well for reusable components, and assertions about business outcomes usually remain in tests so page objects do not conceal test intent.

Practical example

CheckoutPage.placeOrder(address, payment) returns ConfirmationPage, while its private locators and waits remain implementation details.

Detailed explanation

PageFactory and @FindBy can reduce simple field boilerplate, yet they do not solve synchronization or architecture. Explicit By fields often make lookup timing, scoping, and waits clearer, especially for dynamic pages; Page Object Model is a design pattern, not the PageFactory utility.

Practical example

A dynamic order table stores By rowLocator and resolves the row after filtering instead of keeping an annotated WebElement field.

Detailed explanation

Tests send capabilities to a Grid URL, and Grid matches requests to registered slots. Grid 4 can run in standalone, hub-node, or distributed modes and provides observability features, but the test framework still owns test isolation, data, concurrency, and result reporting.

Practical example

CI requests Firefox on Linux and Chrome on Windows through RemoteWebDriver while the same test code runs against both.

Detailed explanation

WebDriver is not designed for concurrent commands from multiple test threads. A driver factory can create a session per invocation, with ThreadLocal used carefully when framework callbacks require thread association; teardown must remove and quit the correct driver.

Practical example

A parallel DataProvider creates a separate browser and unique customer for every row instead of sharing a static driver and account.

Detailed explanation

Headless mode is valuable for CI efficiency but can differ in window size, graphics, downloads, permissions, and resource constraints. Configure options explicitly and collect screenshots, console output, and browser versions so headless-only failures are diagnosable.

Practical example

ChromeOptions adds --headless and --window-size=1440,900 in CI, while a scheduled headed suite checks critical visual interactions.

Detailed explanation

Agree with developers on semantic test attributes for unstable widgets while preferring accessible product attributes when they are durable. Centralize selectors at page or component boundaries, ban generated and absolute paths through review, and migrate based on failure evidence rather than rewriting everything.

Practical example

A design-system button exposes a stable data-testid convention, and component objects scope repeated controls to their owning card.

Detailed explanation

Generic document readiness is insufficient because asynchronous rendering continues after load. Components should wait for precise states such as spinner disappearance, stable result count, enabled controls, or a completed status, while framework code records condition, locator, URL, and timeout context.

Practical example

A search component waits for the previous results container to become stale and for a new result set carrying the requested query token.

Detailed explanation

Tests should state behavior and assertions; page components translate domain actions into UI interactions. Factories create isolated drivers from typed configuration, utilities stay narrow, and dependency direction should not force page objects to know TestNG or reporting internals.

Practical example

An OrderWorkflow composes CatalogPage and CheckoutPage, while DriverFactory and EvidenceListener remain independent infrastructure.

Detailed explanation

On failure, collect screenshot, URL, browser and platform versions, relevant logs, and correlation IDs without leaking secrets. Artifacts need unique names and links from CI; listener errors must be contained so an evidence failure does not replace the assertion or timeout that caused the test to fail.

Practical example

IInvokedMethodListener records the test ID and start time, while ITestListener captures browser evidence only for failed invocations.

Detailed explanation

A fast smoke suite can gate deployment while broader browser coverage runs in parallel or on schedule. CI should inject secrets securely, isolate data, cap concurrency to available resources, retain reports and artifacts, and distinguish infrastructure failures from product failures without automatically masking either.

Practical example

A pull request runs Chrome smoke tests in containers; post-deployment runs cross-browser checkout tests through Grid and publishes Surefire results.

Detailed explanation

Compare failures by browser, node, timing, data, and application version, then reproduce with the same environment. Retries can estimate flakiness or protect a pipeline temporarily, but a pass on retry must remain visible and cannot substitute for fixing synchronization, isolation, locators, or infrastructure.

Practical example

Failure clustering on one Grid node reveals disk pressure causing browser crashes, while a separate stale-element cluster leads to a component wait redesign.

Detailed explanation

These capabilities can observe console messages, network activity, downloads, and browser events that ordinary DOM assertions miss. Use Selenium's supported APIs, feature-detect per browser, and keep protocol-specific diagnostics behind an abstraction because coverage and API stability vary.

Practical example

A framework records severe console errors and request correlation IDs when checkout fails, then links them with server logs.

Detailed explanation

Shadow DOM creates an encapsulation boundary, so document-level CSS or XPath cannot cross it directly. Selenium 4's shadow-root API supports open roots; nested roots must be traversed one boundary at a time, while closed roots are intentionally inaccessible through this mechanism.

Practical example

Find the custom checkout component, get its shadow root, and locate the internal button by a stable CSS selector.

Detailed explanation

Tests should not rely on order, shared accounts, or leftovers from earlier methods. Generate unique identifiers, provision state through APIs or fixtures when the UI setup is not under test, and make cleanup idempotent; when cleanup fails, expiration or namespaced data limits contamination.

Practical example

Each parallel order test creates a customer and product through test-support APIs, verifies one UI journey, and deletes records by unique run ID.

Detailed explanation

Start with stack trace, screenshot, URL, DOM or page source where safe, browser console, driver/browser versions, video, and server correlation data. Determine whether the defect belongs to the product, test code, data, synchronization, browser, Grid, or environment before changing waits or locators.

Practical example

An intercepted click is traced from screenshot and DOM to a loading overlay; network evidence then reveals a slow failed request rather than a bad button locator.

Detailed explanation

I would capture timing, DOM evidence, and the exact stale operation, then verify whether filtering replaces the row or entire table. The component should retain a By locator, wait for staleness of the old container or a query-specific state, and reacquire the row; any retry would be bounded around that known transition.

Practical example

After entering “Pending,” wait for the old results element to become stale and for a row with the created order ID and Pending status to appear.

Detailed explanation

I would preserve screenshot, DOM geometry, browser logs, viewport, and the exception message, which often names the receiving element. Likely causes include overlays, sticky banners, animations, or scroll position; I would reproduce at the CI viewport and wait for the blocker to disappear or fix the product behavior.

Practical example

Evidence shows a progress overlay remains during a slow tax request, so the test waits for its invisibility before clicking and the team investigates the delayed request.

Detailed explanation

I would inspect static drivers, singleton page objects, reused accounts, shared download paths, and listener access to drivers. Each invocation needs its own session and data, and evidence must include a unique test and session identifier; Grid telemetry can then separate node instability from framework cross-talk.

Practical example

A static driver field is overwritten by another TestNG thread, so teardown and screenshots target the wrong session; a per-invocation driver holder removes the race.

Detailed explanation

I would record browser options and versions, resolve the download path inside the CI container, check write permissions and free space, and confirm whether Grid stores the file on a node. Then I would inspect network and application responses and use polling for a completed non-temporary file or Selenium's remote download support as appropriate.

Practical example

The test was polling the runner workspace while Chrome ran on a Grid node; enabling managed downloads and retrieving the artifact fixes the location mismatch.

Detailed explanation

I would correlate failures by account, test, session, node, and response, then remove shared credentials and order dependencies. Each test would receive a known account state, fresh browser context, deterministic cleanup, and waits for a signed-in identity or defined error; retries would remain diagnostic and visible while root causes are fixed.

Practical example

Parallel negative tests were locking the same user used by positive tests, while a reused cookie leaked identity; unique accounts and per-method drivers remove both interactions.