In a TestNG suite configured with parallel="methods" and thread-count=5, tests intermittently interact with the wrong browser window and throw NoSuchWindowException, though each test passes when run alone. The framework holds `private static WebDriver driver;` initialized in a @BeforeMethod. What is the correct root-cause fix?
- A. Store the WebDriver in a `ThreadLocal<WebDriver>` so each thread gets its own isolated instance ✓
- B. Add an implicit wait of 10 seconds so window handles have time to stabilize across threads
- C. Change parallel="methods" to parallel="tests" and keep the static driver
- D. Synchronize every @Test method on the driver object to serialize browser access
Correct answer: A. A single static WebDriver is shared across all threads, so parallel tests clobber each other's session; a ThreadLocal gives each thread its own driver, which is the standard thread-safe pattern.
A Selenium test intermittently fails with ElementNotInteractableException when clicking a 'Confirm' button inside an animated modal. The wait is `new WebDriverWait(driver, Duration.ofSeconds(10)).until(ExpectedConditions.presenceOfElementLocated(By.id("confirm")))`. Why does this fail and what is the minimal fix?
- A. presenceOfElementLocated returns as soon as the node exists in the DOM even if it is hidden or still animating; switch to elementToBeClickable ✓
- B. The timeout is too short; increase it to 30 seconds so the animation completes
- C. presenceOfElementLocated polls too aggressively; add a Thread.sleep(500) before the click
- D. The locator is stale; re-find the element with driver.findElement immediately before clicking
Correct answer: A. presenceOfElementLocated only guarantees DOM presence, not visibility or interactability, so the click can hit a not-yet-interactable element; elementToBeClickable waits for visible and enabled.
A test grabs `WebElement row = driver.findElement(By.css(".grid-row"))`, triggers a filter that causes React to re-render the grid, then calls `row.click()` and gets StaleElementReferenceException. Which statement correctly explains the cause?
- A. The element reference points to a DOM node that was detached/replaced during re-render, so the cached handle is no longer valid ✓
- B. The CSS selector matched multiple elements, so Selenium lost track of which one to click
- C. An implicit wait expired between findElement and click, invalidating the reference
- D. The browser garbage-collected the element because JavaScript held no reference to it
Correct answer: A. StaleElementReferenceException means the previously located node was removed or replaced in the DOM; the fix is to re-locate the element after the re-render rather than reuse the cached reference.
You migrate a click test from Selenium to Playwright. In the app, a cookie banner sometimes overlays the target button. With Selenium's Actions.click the test occasionally clicked the banner instead of the button; in Playwright `page.click('#submit')` now times out with an actionability error instead. Why does Playwright behave differently?
- A. Playwright's auto-waiting runs actionability checks including that the element actually receives pointer events (is not obscured), so it waits/fails rather than clicking the overlay ✓
- B. Playwright disables JavaScript overlays during clicks, so the banner should never appear
- C. Playwright uses a longer default timeout, so the banner has time to auto-dismiss before the click
- D. Playwright clicks via the accessibility tree, which ignores z-index and overlays entirely
Correct answer: A. Playwright's actionability checks require the target to be visible, stable, enabled, and hit-testable (receiving events); an obscuring overlay fails the hit-test, producing a timeout instead of a wrong-element click.
A data-validation check runs `SELECT * FROM orders WHERE customer_id NOT IN (SELECT id FROM customers);` to find orphaned orders. The customers table has at least one row where id IS NULL. What does the query return?
- A. Zero rows, regardless of how many orphaned orders actually exist ✓
- B. All orphaned orders correctly, because NULL ids are simply skipped in the subquery
- C. A syntax error, because NOT IN cannot operate on a nullable column
- D. Only orders whose customer_id is also NULL
Correct answer: A. With NOT IN, a NULL in the subquery makes every comparison evaluate to UNKNOWN rather than TRUE, so the predicate is never satisfied and no rows are returned; NOT EXISTS or filtering out NULLs avoids this trap.
An SLA states 95% of checkout requests must complete under 500ms. Your k6 run reports http_req_duration avg=210ms, med=180ms, p(95)=830ms, max=4s. What is the correct conclusion for the release gate?
- A. Fail the gate: the p95 of 830ms exceeds the 500ms threshold, and the low average masks a slow tail ✓
- B. Pass the gate: the average and median are well under 500ms
- C. Pass the gate: only the max is over 500ms and maximums are always outliers to ignore
- D. Inconclusive: k6 cannot evaluate percentile-based SLAs without a longer soak test
Correct answer: A. A 95th-percentile SLA is evaluated against p95, which at 830ms violates the 500ms limit; averages and medians hide tail latency and must not be used to certify a percentile SLA.
In WireMock, two stub mappings both match GET /accounts/123: stub A has `"priority": 5` returning 200, stub B has `"priority": 1` returning 404. Which response is served, and why?
- A. The 404 from stub B, because a lower priority number means higher precedence and is evaluated first ✓
- B. The 200 from stub A, because higher priority numbers win
- C. WireMock returns a 500 because ambiguous overlapping stubs are a configuration error
- D. Whichever stub was registered last, because priority only breaks ties by insertion order
Correct answer: A. In WireMock a lower priority value denotes higher precedence, so stub B (priority 1) is matched before stub A and its 404 is returned.
A consumer service publishes a Pact contract expecting the provider's GET /user/{id} response to include a non-null `email` string. The provider team refactors and drops `email` from the payload. Assuming CI runs Pact provider verification against the published pact, what happens and why?
- A. Provider verification fails, because the recorded consumer expectation (email present) is no longer satisfied by the real provider response ✓
- B. Nothing fails, because Pact only verifies request shapes, not response bodies
- C. The consumer's own unit tests fail, but provider verification passes since it replays stubs
- D. Verification passes because Pact treats missing fields as backward-compatible by default
Correct answer: A. Provider verification replays the consumer's recorded expectations against the real provider; removing a field the consumer relied upon breaks that expectation and fails verification, catching the contract mismatch before deploy.
A field accepts an integer age and is valid only for 18 through 65 inclusive. Applying two-value boundary value analysis (just below, at, above each boundary), which set of test inputs is correct?
- A. 17, 18, 65, 66 ✓
- B. 18, 19, 64, 65
- C. 0, 18, 65, 100
- D. 17, 19, 64, 66
Correct answer: A. Two-value BVA tests each boundary and its immediate outside neighbor: min-1=17, min=18, max=65, max+1=66.
A configuration form has 3 independent boolean flags (each on/off). Exhaustive testing needs 2^3 = 8 cases, but you decide pairwise (all-pairs) coverage is sufficient. What is the minimum number of test cases that covers every pair of flag values?
Correct answer: A. For three two-valued parameters, an orthogonal all-pairs set of 4 cases covers every pairwise value combination, halving the exhaustive 8.