A4Q Selenium Tester Mock Exam #2 — Questions & Answers
Every question in this mock exam, with the correct answer marked and a written rationale behind each option below — for reading and review, not a timed run.
In Selenium 4, what is the primary role of the WebDriver interface?
It defines a common, browser-agnostic API that concrete drivers (ChromeDriver, FirefoxDriver) implement to drive a real browser.
Correct — WebDriver is the interface; each browser driver implements it, so the same test code drives any supported browser.
It renders the web page itself, replacing the browser engine.
Wrong — WebDriver does not render pages; the browser engine does. WebDriver only sends commands to the browser.
It is a test runner that discovers and executes test cases.
Wrong — running and reporting tests is the job of a framework like JUnit, TestNG or pytest, not WebDriver.
It is an assertion library for verifying expected results.
Wrong — assertions come from the test framework or an assertion library; WebDriver only provides browser automation commands.
WebDriver defines a browser-agnostic API; a browser-specific driver class implements it and controls a real browser.
Which communication protocol does Selenium 4 use between the client bindings and the browser driver by default?
The W3C WebDriver protocol.
Correct — Selenium 4 uses the W3C WebDriver standard exclusively, improving cross-browser stability.
The legacy JSON Wire Protocol.
Wrong — the JSON Wire Protocol was used in Selenium 3 and earlier and is removed in Selenium 4.
FTP.
Wrong — FTP is a file-transfer protocol and is unrelated to browser automation.
SMTP.
Wrong — SMTP is an email protocol; it plays no part in driving a browser.
Selenium 4 is fully standardised on the W3C WebDriver protocol; the legacy JSON Wire Protocol was removed.
What is the difference between driver.quit() and driver.close()?
close() closes only the current browser window/tab, while quit() ends the entire WebDriver session and closes all windows.
Correct — this is the defining distinction; use quit() in teardown to free the driver process.
They are identical; both end the session.
Wrong — only quit() ends the session. close() leaves the session alive with any remaining windows.
quit() closes only the current tab; close() ends the whole session.
Wrong — this reverses the two methods.
close() clears cookies; quit() reloads the page.
Wrong — neither method is about cookies or reloading; both are about closing windows/sessions.
close() closes the current window; quit() ends the whole session and disposes the driver.
Which of the following are valid navigation commands provided by the WebDriver.Navigation interface? Select TWO.
navigate().refresh()
Correct — refresh() reloads the current page and is part of the Navigation interface.
navigate().back()
Correct — back() moves one step back in browser history and is part of the Navigation interface.
navigate().scroll()
Wrong — there is no scroll() on the Navigation interface; scrolling is done via Actions or JavaScript.
navigate().click()
Wrong — click() is a WebElement method, not a navigation command.
navigate().back(), forward(), refresh() and to(url) belong to the Navigation interface.
A test opens a link that spawns a second browser window. Which pair of methods lets the test enumerate open windows and switch focus to the new one?
getWindowHandles() and switchTo().window(handle)
Correct — getWindowHandles() returns the set of handles and switchTo().window() moves the driver's focus to the chosen window.
getWindowHandle() and switchTo().frame(index)
Wrong — getWindowHandle() (singular) returns only the current handle, and frame() switches into iframes, not windows.
findElements() and click()
Wrong — these locate and click elements; they do not manage window focus.
navigate().to() and get()
Wrong — these load a URL in the current window and do not switch between existing windows.
getWindowHandles() returns all handles; switchTo().window(handle) changes focus.
A tester runs the following Java code against a page that takes about 3 seconds to render the search box after the page 'load' event fires:
WebDriver driver = new ChromeDriver();
driver.get("https://shop.example.com");
driver.findElement(By.id("search")).sendKeys("laptop");
No implicit or explicit wait is configured. What is the MOST likely result?
A NoSuchElementException is thrown because findElement runs before the search box is rendered.
Correct — get() returns at the load event; the element appears ~3s later, so with no wait the lookup fails immediately.
Selenium automatically waits until the element appears and then types the text.
Wrong — WebDriver does not wait automatically; without a configured wait it does not poll for the element.
The text is typed successfully because get() blocks until all asynchronous content is loaded.
Wrong — get() blocks only until the load event, not until asynchronous rendering completes.
A TimeoutException is thrown after the default 30-second timeout.
Wrong — no wait is configured, so there is no polling timeout; the failure is an immediate NoSuchElementException.
driver.get() blocks only until the load event, not until asynchronous content appears. With no wait, findElement runs immediately and the element is not yet present, so a NoSuchElementException is thrown.
In Selenium 4, how should browser-specific configuration such as headless mode or a custom download directory be passed when creating a driver?
By building a browser Options object (e.g. ChromeOptions) and passing it to the driver constructor.
Correct — Options classes are the Selenium 4 mechanism for capabilities and browser flags.
By instantiating the deprecated DesiredCapabilities class and passing it directly.
Wrong — DesiredCapabilities was deprecated and removed as a constructor argument in Selenium 4; Options replaced it.
By editing the browser's own settings file on disk before the run.
Wrong — this is fragile and not the WebDriver-supported approach; Options provides a programmatic, portable API.
Configuration cannot be changed; the driver always uses browser defaults.
Wrong — configuration is fully supported via Options; the driver does not force defaults.
Selenium 4 removed DesiredCapabilities; browser Options classes (ChromeOptions, FirefoxOptions) are the supported way to configure a session.
Which statements about Selenium WebDriver are correct? Select TWO.
It controls a real browser through a browser-specific driver executable (e.g. chromedriver).
Correct — each browser has a driver executable that WebDriver commands are sent to.
It can run the browser in headless mode for CI environments.
Correct — headless mode (via Options) is commonly used on servers without a display.
It is a record-and-playback tool that requires no programming.
Wrong — that describes Selenium IDE; WebDriver is a programming API.
It can test native desktop applications without a browser.
Wrong — WebDriver automates browsers; native desktop apps need tools like WinAppDriver or Appium.
WebDriver drives a real browser via the browser's own driver executable and works headless; it is not a record-and-playback IDE.
Given the HTML below, which locator uniquely selects the email input?
<form id="signup"><input name="email" type="email" class="field"><input name="phone" type="tel" class="field"></form>
By.cssSelector("input[name='email']")
Correct — the name attribute is unique to the email field, so this CSS selector matches exactly one element.
By.className("field")
Wrong — both inputs have class 'field', so this matches two elements and findElement returns the first (the wrong one).
By.id("email")
Wrong — there is no element with id 'email'; the email field only has a name attribute.
By.tagName("input")
Wrong — there are two input elements, so this is ambiguous and returns the first match.
Both inputs share class 'field', so By.className is ambiguous. The name attribute 'email' is unique.
According to Selenium good practice, why is By.id() usually preferred over an absolute XPath such as /html/body/div[2]/form/input[1]?
A stable id is unique and resilient to layout changes, whereas an absolute XPath breaks when the DOM structure shifts.
Correct — absolute paths are brittle; a stable id keeps locating the element after markup reordering.
Absolute XPath cannot be used in Selenium 4 at all.
Wrong — absolute XPath still works; it is just discouraged because it is fragile.
IDs are always slower to evaluate than XPath.
Wrong — the opposite is generally true; id lookups are typically the fastest locator strategy.
Absolute XPath guarantees a unique match, so it is the most reliable option.
Wrong — it may be unique at one moment but is highly sensitive to structural changes, making it unreliable over time.
IDs (when present and stable) are fast and resilient; absolute XPath breaks whenever the DOM structure changes.
Which XPath selects the button whose visible text is exactly 'Add to cart'?
<button class="btn primary">Add to cart</button>
//button[normalize-space(text())='Add to cart']
Correct — this matches the button by its trimmed visible text, which is robust to leading/trailing whitespace.
//button[@text='Add to cart']
Wrong — there is no 'text' attribute on the button; visible text is not an attribute in HTML.
//button[@class='Add to cart']
Wrong — this matches on the class attribute, whose value is 'btn primary', not the button text.
//button#Add to cart
Wrong — '#' is CSS id syntax and is invalid inside an XPath expression.
XPath text() with normalize-space matches on the visible text content of the element.
Which CSS selector matches a link whose href attribute ENDS WITH '.pdf'?
<a href="/files/report.pdf">Download report</a>
a[href$='.pdf']
Correct — the $= operator matches attribute values that end with the given string.
a[href^='.pdf']
Wrong — ^= matches values that START with the string; the href starts with '/files', not '.pdf'.
a[href='.pdf']
Wrong — = requires the whole attribute value to equal '.pdf', which it does not.
a[href~='.pdf']
Wrong — ~= matches a whitespace-separated word within the value, which does not apply to a URL ending.
CSS attribute selector [attr$='value'] matches when the attribute value ends with the given substring.
What is the practical difference between driver.findElement() and driver.findElements()?
findElement returns the first match and throws NoSuchElementException if none is found; findElements returns a (possibly empty) list without throwing.
Correct — findElements is the safe choice when an element may be absent, since it returns an empty list.
Both throw NoSuchElementException when no element matches.
Wrong — findElements does not throw; it returns an empty list.
findElements returns only the first matching element.
Wrong — findElements returns all matching elements as a list; findElement returns only the first.
findElement can only be used with By.id.
Wrong — findElement works with any By locator strategy.
findElement throws NoSuchElementException when nothing matches; findElements returns an empty list.
Which of the following are advantages of CSS selectors over XPath in Selenium? Select TWO.
CSS selectors are generally faster to evaluate in most browser engines.
Correct — native CSS engine evaluation is typically faster than XPath in most browsers.
CSS syntax is often more concise for id, class and attribute matching.
Correct — for common lookups CSS is usually shorter and easier to read than the XPath equivalent.
CSS selectors can navigate to a parent or ancestor element.
Wrong — CSS cannot select ancestors; only XPath supports parent/ancestor axes.
CSS selectors can locate an element by its visible text.
Wrong — CSS cannot match on text content; XPath can with text()/normalize-space().
CSS selectors are generally faster in most browser engines and have more concise syntax for common cases; but CSS cannot traverse to parent/ancestor nodes and cannot match on visible text.
A row in a data table must be located by the text in its second cell. Which XPath finds the <tr> that contains a <td> with text 'Invoice #4521'?
<tr><td>2026-07-01</td><td>Invoice #4521</td></tr>
//tr[td[normalize-space()='Invoice #4521']]
Correct — this selects the tr that has a td child with the given text, returning the whole row.
//td[text()='Invoice #4521']
Wrong — this returns the cell itself, not the parent row that was requested.
//tr/td::parent[text()='Invoice #4521']
Wrong — 'td::parent' is not valid XPath axis syntax; the parent axis is written as parent::tr.
tr:has(td:contains('Invoice #4521'))
Wrong — :contains() is not a standard CSS selector supported by Selenium, and this mixes CSS with the request for XPath.
XPath can select an ancestor row from a descendant cell using the pattern //td[...]/parent::tr or //tr[td[...]].
A team uses locators tied to auto-generated class names like 'css-1x9k2f'. Why is this a poor locator strategy?
Auto-generated class names change between builds, so the locators become invalid unpredictably.
Correct — hashed class names are volatile; a stable data-testid or id is far more reliable.
Selenium cannot use class names as locators at all.
Wrong — Selenium fully supports class-based locators; the issue is the instability of these particular names.
Class-name locators are always slower than id locators, causing timeouts.
Wrong — the core problem is instability, not speed; performance is not the reason these locators fail.
Class names cannot contain digits, so 'css-1x9k2f' is invalid HTML.
Wrong — class names may contain digits; such names are valid HTML, just unstable.
Auto-generated class names (from CSS-in-JS build tools) change on rebuilds, so locators bound to them break unpredictably.
What is the core idea of the Page Object Model (POM)?
Each page (or component) is represented by a class that encapsulates its locators and interactions, keeping tests free of raw locators.
Correct — this separation of concerns is the essence of POM and improves maintainability.
It stores all test data in a single JSON file per page.
Wrong — that describes data-driven testing, not the Page Object Model.
It replaces WebDriver with a screenshot-comparison engine.
Wrong — POM is a design pattern for organising code, not a visual-testing technique.
It requires every test to be written in Gherkin syntax.
Wrong — Gherkin is a BDD notation and is independent of POM.
POM encapsulates a page's locators and interactions behind a class, separating them from the test logic.
In a well-designed Page Object, where should assertions (verifying expected outcomes) normally live?
In the test methods; the Page Object exposes actions and getters but leaves verification to the tests.
Correct — keeping assertions out of page objects makes them reusable across many tests with different expectations.
Inside every Page Object method, so each action self-verifies.
Wrong — embedding assertions couples page objects to specific expectations and hurts reuse.
In the WebDriver driver class.
Wrong — the driver is a low-level browser controller and is not where test verification belongs.
Assertions are never needed when POM is used.
Wrong — tests still need assertions; POM only changes where the locators live, not whether verification happens.
Page Objects model page behaviour and return state; assertions belong in the test methods, keeping page objects reusable.
When a Page Object method performs an action that navigates the user to a different page, what is a recommended return value?
An instance of the Page Object representing the destination page.
Correct — returning the next page object supports a fluent API and documents the navigation in code.
The raw HTML source of the new page as a String.
Wrong — returning raw HTML defeats the abstraction POM provides and is hard to work with.
The WebDriver instance itself.
Wrong — exposing the driver leaks low-level details into tests, undermining the page abstraction.
Always void; page methods should never return anything.
Wrong — while some actions return void, navigation methods benefit from returning the destination page object.
Returning the next Page Object enables fluent chaining and models the navigation flow explicitly.
Which of the following are benefits of using the Page Object Model? Select TWO.
When a locator changes, it is updated in one place instead of across many tests.
Correct — centralising locators is a primary maintainability benefit of POM.
Tests read as business actions (e.g. loginPage.loginAs(user)) rather than low-level locator calls.
Correct — higher-level, readable test code is a key advantage of encapsulating pages.
It removes the need for any waits or synchronisation.
Wrong — POM does not address timing; waits are still required for dynamic content.
It makes tests run in parallel automatically.
Wrong — parallel execution is configured by the test framework/runner, not provided by POM.
POM centralises locators (one place to update on UI change) and improves readability/reuse of test code.
What does the term 'Page Factory' refer to in the context of Selenium Page Objects (Java)?
A Selenium support class that initialises WebElement fields annotated with @FindBy in a page object.
Correct — PageFactory.initElements() wires up @FindBy fields lazily, a classic POM helper in the Java bindings.
A design pattern for creating browser driver instances.
Wrong — that describes a driver factory; Page Factory initialises page-object element fields.
A tool that generates HTML pages for testing.
Wrong — PageFactory does not generate pages; it wires locators to fields.
A reporting library for test results.
Wrong — reporting is unrelated to PageFactory, which is about element initialisation.
PageFactory is a Selenium support class that initialises @FindBy-annotated fields via PageFactory.initElements().
A test suite has one giant page object containing 200 elements and 80 methods for the entire application. From a design standpoint, what is the main problem?
It breaks the single-responsibility principle; each page or component should have its own focused page object.
Correct — a god-object page is hard to maintain; POM works best when classes map to individual pages/components.
Nothing; one large page object is the recommended POM approach.
Wrong — POM recommends one class per page/component, not a single monolith.
WebDriver cannot handle more than 100 elements in one class.
Wrong — there is no such technical limit; the issue is design/maintainability, not a WebDriver cap.
Page objects must never contain more than one method.
Wrong — page objects can have many methods; the problem is scope, not method count per se.
A single monolithic page object violates the model; each page/component should be its own class to stay cohesive and maintainable.
What is the key difference between an implicit wait and an explicit wait in Selenium WebDriver?
An implicit wait applies globally to every element lookup, while an explicit wait waits for a specific condition on a specific element.
Correct — explicit waits are condition-based and targeted; implicit waits set a blanket polling timeout for all findElement calls.
An implicit wait pauses execution for a fixed number of seconds every time, like Thread.sleep.
Wrong — that describes a hard sleep; an implicit wait only waits up to the timeout and returns as soon as the element is found.
An explicit wait applies to all elements and cannot target a condition.
Wrong — this reverses the concepts; explicit waits are precisely for targeting a specific condition.
There is no difference; the two terms are synonyms.
Wrong — they are distinct mechanisms with different scope and behaviour.
Implicit wait applies globally to all element lookups; explicit wait targets a specific condition on a specific element.
A tester wants to wait until a spinner disappears and the results become clickable. Which Java snippet is the correct explicit-wait approach in Selenium 4?
new WebDriverWait(driver, Duration.ofSeconds(10)).until(ExpectedConditions.elementToBeClickable(By.id("result")))
Correct — Selenium 4 takes a Duration and polls until the ExpectedCondition is met or the timeout elapses.
Thread.sleep(10000); driver.findElement(By.id("result")).click();
Wrong — a fixed sleep is not an explicit wait; it wastes time when fast and still fails when slow.
driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10)); driver.findElement(By.id("result")).click();
Wrong — an implicit wait waits for presence, not clickability, so it can click an element that is present but not yet interactable.
driver.wait(10).click(By.id("result"));
Wrong — there is no such driver.wait(...).click() API in Selenium; this is invalid.
WebDriverWait with Duration and an ExpectedConditions method (e.g. elementToBeClickable) is the idiomatic Selenium 4 explicit wait.
Why is mixing implicit and explicit waits in the same test discouraged?
The two mechanisms can compound, leading to unpredictable and unexpectedly long wait times.
Correct — the interaction between implicit and explicit polling is undefined and can add up, so official guidance is to avoid mixing them.
Selenium throws a compile-time error if both are configured.
Wrong — there is no compile-time error; the code runs but timing becomes unreliable.
Explicit waits stop working entirely once an implicit wait is set.
Wrong — explicit waits still function; the problem is unpredictable combined timing, not total failure.
Because implicit waits are not supported in Selenium 4.
Wrong — implicit waits are still supported; they are simply not recommended together with explicit waits.
Combining them can produce unpredictable, longer-than-expected wait times because the two mechanisms interact.
What is a FluentWait and how does it extend the basic explicit wait?
A wait that lets you set the timeout, the polling interval, and which exceptions to ignore while waiting.
Correct — FluentWait exposes withTimeout, pollingEvery and ignoring, giving fine-grained control over the wait.
A wait that never times out and blocks the test forever.
Wrong — FluentWait always has a configured timeout; it does not block indefinitely.
A wait applied automatically to all elements without any code.
Wrong — that describes an implicit wait; FluentWait must be created and used explicitly.
A wait that only works with By.id locators.
Wrong — FluentWait works with any condition/function, not just id locators.
FluentWait lets you configure timeout, polling interval and ignored exceptions explicitly.
Which of the following are valid ExpectedConditions commonly used with WebDriverWait? Select TWO.
ExpectedConditions.visibilityOfElementLocated(By)
Correct — waits until the element is present in the DOM and visible.
ExpectedConditions.elementToBeClickable(By)
Correct — waits until the element is visible and enabled so it can be clicked.
ExpectedConditions.pageToBeBeautiful()
Wrong — no such condition exists; it is not part of the Selenium API.
ExpectedConditions.networkIdleForever()
Wrong — this is not a real ExpectedCondition in Selenium.
visibilityOfElementLocated and elementToBeClickable are standard ExpectedConditions; the others are invented.
Why is using Thread.sleep() for synchronisation considered an anti-pattern in Selenium tests?
It always waits the full fixed time even if the element is ready sooner, and may still be too short on a slow run — slow and flaky.
Correct — a hard sleep cannot adapt to actual timing, so it wastes time and still fails intermittently; conditional waits are better.
Thread.sleep() is not available in Java, so the code will not compile.
Wrong — Thread.sleep() is standard Java; the objection is behavioural, not a compile error.
It closes the browser session unexpectedly.
Wrong — sleeping does not close the session; it merely pauses the thread.
It makes the browser run in headless mode.
Wrong — Thread.sleep has nothing to do with headless mode.
A fixed sleep always waits the full duration regardless of readiness, making tests both slow and flaky.
A page shows content inside an <iframe>. A test fails with NoSuchElementException when locating an element that is clearly visible inside the frame. What is the most likely cause?
The driver has not switched into the iframe, so the element is outside its current search context.
Correct — you must call driver.switchTo().frame(...) before locating elements inside an iframe.
Selenium cannot interact with elements inside iframes at all.
Wrong — Selenium fully supports iframe content after switching into the frame.
The element must be located with By.id only when inside an iframe.
Wrong — any locator works inside a frame once you have switched to it; the strategy is not the issue.
iframes automatically close the WebDriver session.
Wrong — iframes do not close sessions; the failure is a search-context issue.
Elements inside an iframe are not reachable until the driver switches into that frame with switchTo().frame().
Which Selenium 4 API is designed for complex interactions such as drag-and-drop, hover, and key-combination sequences?
The Actions class (Actions API).
Correct — Actions builds chains like moveToElement, clickAndHold, dragAndDrop and keyDown/keyUp.
The By class.
Wrong — By defines locator strategies, not interaction sequences.
The ExpectedConditions class.
Wrong — ExpectedConditions supplies wait conditions, not user-input actions.
The Select class.
Wrong — Select handles <select> dropdowns only, not drag-and-drop or hover.
The Actions class builds low-level input sequences (mouse, keyboard) for advanced interactions.
A dropdown is built with a standard HTML <select> element:
<select id="country"><option value="us">USA</option><option value="de">Germany</option></select>
Which is the correct Selenium way (Java) to choose 'Germany'?
new Select(driver.findElement(By.id("country"))).selectByVisibleText("Germany");
Correct — the Select class is the proper API for standard <select> elements; selectByVisibleText picks the option by its text.
driver.findElement(By.id("country")).sendKeys("Germany");
Wrong — sending keys to the select is unreliable; the Select class is the correct, portable approach.
driver.findElement(By.id("country")).selectOption("Germany");
Wrong — WebElement has no selectOption() method in Selenium's Java bindings.
new Actions(driver).selectByVisibleText("Germany").perform();
Wrong — selectByVisibleText is a Select method, not an Actions method.
For a real <select>, use the Select support class; selectByVisibleText('Germany') or selectByValue('de') is idiomatic.
A JavaScript alert() pops up during a test. How does WebDriver interact with it?
By switching to it with driver.switchTo().alert() and calling accept() or dismiss().
Correct — alerts are a separate context reached via switchTo().alert(); you then accept, dismiss or type into it.
By locating it with By.id("alert") and clicking the OK button.
Wrong — native JS alerts are not part of the DOM and cannot be located with By strategies.
WebDriver cannot handle JavaScript alerts.
Wrong — WebDriver handles alerts through the Alert interface.
By refreshing the page to make the alert disappear.
Wrong — refreshing does not properly handle the alert and can leave the browser in a blocked state.
JavaScript alerts are handled via driver.switchTo().alert(), then accept()/dismiss()/sendKeys().
What does driver.getWindowHandle() (singular) return?
A String identifying the currently focused window.
Correct — the singular method returns the handle of the current window as a String.
A list of all open window handles.
Wrong — that is getWindowHandles() (plural); the singular returns one handle.
The window's pixel dimensions.
Wrong — dimensions come from manage().window().getSize(), not getWindowHandle().
The page title of the current window.
Wrong — the title is returned by driver.getTitle(), not getWindowHandle().
getWindowHandle() returns the string handle of the current focused window; getWindowHandles() (plural) returns all.
Which statements about handling multiple browser tabs/windows in Selenium 4 are correct? Select TWO.
Selenium 4 can open a new tab directly with driver.switchTo().newWindow(WindowType.TAB).
Correct — newWindow is a Selenium 4 addition that opens and switches to a new tab or window.
You identify and switch between windows using their window handles.
Correct — handles are the stable identifiers used to switch focus between open windows/tabs.
WebDriver automatically switches focus to a newly opened tab.
Wrong — opening a link in a new tab does not move focus; you must switch explicitly by handle.
Window handles are sequential integers starting at 0.
Wrong — handles are opaque strings assigned by the browser, not ordered integers.
Selenium 4 adds driver.switchTo().newWindow(WindowType.TAB) to open a new tab; you still track windows via handles.
What is a 'flaky' automated test?
A test that passes and fails intermittently on the same code without a clear reason.
Correct — flakiness means non-deterministic results, often caused by timing, ordering or environment issues.
A test that always fails on every run.
Wrong — a consistently failing test is deterministic, not flaky.
A test that has no assertions.
Wrong — lacking assertions is a different quality problem, not flakiness.
A test that runs only in headless mode.
Wrong — headless execution is unrelated to the definition of flakiness.
A flaky test passes and fails intermittently without any change to the code under test.
A test intermittently fails when clicking a button that is present in the DOM but sometimes still animating into place. Which fix best addresses the root cause?
Use an explicit wait for ExpectedConditions.elementToBeClickable before clicking.
Correct — this waits until the element is both visible and enabled, matching the real precondition for a reliable click.
Add Thread.sleep(500) before every click.
Wrong — a fixed sleep is a fragile band-aid; it wastes time and can still be too short under load.
Retry the whole test three times and accept the first pass.
Wrong — blind retries hide the timing defect rather than fixing the synchronisation.
Switch the locator from CSS to XPath.
Wrong — the locator strategy is not the problem; the element is found but not yet interactable.
Waiting for elementToBeClickable (visible AND enabled) synchronises on interactability, unlike presence alone.
Which practices help make Selenium tests more stable and less flaky? Select TWO.
Make each test independent, setting up and cleaning up its own data.
Correct — test isolation prevents failures caused by leftover state or execution order.
Synchronise on state with condition-based explicit waits instead of fixed sleeps.
Correct — waiting for the actual condition adapts to real timing and avoids both wasted time and premature actions.
Share one browser session and accumulated state across all tests.
Wrong — shared mutable state couples tests and is a common source of flakiness.
Insert longer Thread.sleep() calls wherever a test occasionally fails.
Wrong — fixed sleeps do not adapt to timing and mask, rather than fix, the underlying synchronisation issue.
Independent tests with their own data and condition-based explicit waits both reduce flakiness; shared state and fixed sleeps increase it.
A CI pipeline runs a Selenium suite in parallel across many threads. Several tests intermittently fail because they log in as the same shared user and interfere with each other's data. Which change most directly removes this flakiness?
Give each parallel test its own isolated test user and data set.
Correct — removing shared mutable state between parallel tests eliminates the cross-interference at its source.
Increase the implicit wait to 60 seconds.
Wrong — the failures are due to data collisions, not timing; a longer wait does not prevent shared-data interference.
Run the suite in headless mode.
Wrong — headless mode changes rendering, not data isolation; the collision persists.
Switch all locators to absolute XPath.
Wrong — locator strategy is irrelevant here; the issue is shared data between concurrent tests.
The root cause is shared test data across parallel threads; giving each test its own isolated user/data removes the interference.
Why is capturing a screenshot on test failure a recommended stability/diagnostics practice?
It records the UI state at the moment of failure, making it much easier to diagnose intermittent problems.
Correct — a screenshot (and often page source/logs) at failure time is invaluable for debugging flaky or environment-specific failures.
It prevents the test from ever failing again.
Wrong — a screenshot is a diagnostic artefact; it does not change test outcomes.
It makes the browser run faster.
Wrong — taking a screenshot does not improve execution speed.
It automatically fixes broken locators.
Wrong — a screenshot only captures state; it cannot repair locators.
A failure screenshot captures the UI state at the moment of failure, greatly speeding up root-cause analysis.
A team wants to run the same Selenium suite across Chrome, Firefox and Edge on a shared infrastructure. Which Selenium component is designed for this distributed, cross-browser execution?
Selenium Grid.
Correct — Grid routes tests to nodes running different browsers/OS, enabling distributed, parallel cross-browser runs.
Selenium IDE.
Wrong — Selenium IDE is a browser record-and-playback extension, not a distributed execution grid.
The Actions class.
Wrong — Actions handles complex input gestures, not distributed test execution.
The PageFactory class.
Wrong — PageFactory initialises page-object fields; it has nothing to do with distributed execution.
Selenium Grid distributes tests across multiple machines/browsers, enabling parallel cross-browser execution.