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.
A test passes locally but intermittently fails in CI. The MOST likely root cause is:
- A. A syntax error in the test file
- B. The assertion library being outdated
- C. Hidden dependencies on timing, ordering, or shared state ✓
- D. The test having too many comments
Correct answer: C. Intermittent CI-only failures are the hallmark of flakiness caused by timing, execution order, or shared/mutable state.
Mixing Selenium implicit and explicit waits in the same test is discouraged because it can:
- A. Cause unpredictable, compounded wait times ✓
- B. Disable JavaScript execution on the page
- C. Prevent the browser from launching
- D. Always double every element's locator
Correct answer: A. The two wait mechanisms can stack unpredictably, producing inconsistent and often longer waits.
An HTTP method is idempotent if:
- A. It always returns a 200 status code
- B. Multiple identical requests have the same effect as a single one ✓
- C. It can only be called once per session
- D. It never modifies server state under any condition
Correct answer: B. Idempotency means repeating the same request yields the same server state as making it once (e.g., PUT, DELETE).
According to the test automation pyramid, the largest number of tests should be:
- A. End-to-end UI tests at the top
- B. Manual exploratory tests
- C. Performance tests
- D. Unit tests at the base ✓
Correct answer: D. The pyramid advocates many fast, cheap unit tests at the base and few slow end-to-end tests at the top.
Mutation testing evaluates the quality of a test suite by:
- A. Introducing small code changes and checking if tests catch them ✓
- B. Measuring how many lines of code are executed
- C. Randomly generating input data for fuzzing
- D. Counting the number of assertions per test
Correct answer: A. Mutation testing injects small faults (mutants); a good suite should fail (kill) them, revealing weak tests.
A function has a cyclomatic complexity of 5. The minimum number of independent basis paths to cover is:
Correct answer: C. Cyclomatic complexity equals the number of independent paths, so 5 basis-path test cases are needed.
Why can a suite achieve 100% statement coverage yet still miss a decision outcome (branch)?
- A. Statement coverage requires more tests than branch coverage
- B. An if-statement with no else body has a branch with no statements to cover ✓
- C. Branch coverage is always a subset of statement coverage
- D. 100% statement coverage is impossible in practice
Correct answer: B. An if without an else has a false-branch containing no statements, so it can be skipped while all statements still execute.
Consumer-driven contract testing (e.g., Pact) primarily verifies that:
- A. The database indexes are optimized
- B. The UI renders correctly on mobile
- C. The service can handle peak concurrent load
- D. A service's API meets the expectations its consumers actually rely on ✓
Correct answer: D. Contract testing checks a provider against the exact request/response expectations its consumers depend on.
When running tests in parallel, the most common cause of intermittent failures is:
- A. Shared mutable state such as a common database or global variables ✓
- B. Having too few assertions
- C. Using descriptive test names
- D. Running on a faster CPU
Correct answer: A. Parallel tests that share mutable state (DB rows, globals, files) interfere with each other, causing nondeterministic failures.
Testing an integer field that stores a 32-bit signed value, the most important edge case to include is:
- A. Only the value 0
- B. Only negative single digits
- C. 2147483647 and 2147483648 to check for overflow ✓
- D. Only three-digit numbers
Correct answer: C. 2147483647 is the max signed 32-bit int, and 2147483648 crosses it, exposing potential integer overflow.
A test suite of 500 tests takes 40 minutes and blocks deploys. Which strategy BEST reduces feedback time without losing meaningful coverage?
- A. Delete all integration tests
- B. Parallelize tests and shard by execution time ✓
- C. Run every test twice to confirm results
- D. Convert all tests to manual
Correct answer: B. Parallelizing and sharding by historical runtime distributes work evenly across workers, cutting wall-clock time while keeping coverage.
Two independent conditions A and B each affect an outcome. To satisfy MC/DC (Modified Condition/Decision Coverage), you must show that:
- A. Every combination of A and B is tested
- B. Each condition independently affects the decision's outcome ✓
- C. Only the true branch is exercised
- D. The decision is evaluated at least once
Correct answer: B. MC/DC requires demonstrating that each condition independently toggles the overall decision outcome, avoiding full combinatorial explosion.
An automated UI test flakes because it clicks a button before an async XHR-triggered re-render completes. The MOST robust fix is to:
- A. Add a fixed Thread.sleep(3000)
- B. Wait explicitly for the post-render element/state to be present and stable ✓
- C. Retry the whole test on failure
- D. Disable JavaScript during the test
Correct answer: B. Explicitly waiting for the specific post-render condition synchronizes on actual application state rather than guessing with fixed delays.
You have 20 parameters each with 3 possible values. Exhaustive testing is impossible. Which technique gives strong defect detection with far fewer cases?
- A. Random testing
- B. Pairwise (all-pairs) combinatorial testing ✓
- C. Boundary value analysis
- D. Exploratory testing
Correct answer: B. Pairwise testing covers all two-way parameter interactions, catching most interaction defects with a fraction of exhaustive combinations.
In a flaky-test triage, a test fails only when run after a specific other test. The likely root cause is:
- A. Insufficient assertions
- B. Shared mutable state / test ordering dependency ✓
- C. Too many parallel threads
- D. A compiler optimization bug
Correct answer: B. Order-dependent failures typically stem from tests sharing mutable state (DB rows, globals) without proper isolation or cleanup.
A mutation testing run reports a mutation score of 40% while line coverage is 95%. What does this reveal?
- A. The tests run too slowly
- B. Tests execute the code but do not assert enough to catch behavioral changes ✓
- C. The coverage tool is misconfigured
- D. The code has no branches
Correct answer: B. High line coverage with low mutation score means code is exercised but assertions are weak, so injected faults survive undetected.
When testing a distributed system for eventual consistency, a test reads immediately after a write and sees stale data. The correct test design is to:
- A. Assert the value once with no delay
- B. Poll/retry with a bounded timeout until the expected value or timeout ✓
- C. Mark the feature as defective
- D. Disable replication during the test
Correct answer: B. Eventual consistency requires polling within a bounded window, since the correct value may appear only after replication propagates.
You are asked to reduce a regression suite that grew redundant. Which metric best guides which tests to keep for defect-finding value?
- A. Alphabetical test name order
- B. Historical fault detection and unique code/requirement coverage contribution ✓
- C. Execution time only
- D. Number of assertions per test
Correct answer: B. Test suite minimization keeps tests that add unique coverage and have historically caught defects, removing purely redundant ones.
A load test shows p50 latency is fine but p99 spikes badly under load. This pattern most commonly points to:
- A. A steady CPU-bound bottleneck affecting all requests equally
- B. Tail latency from contention like GC pauses, lock waits, or queueing ✓
- C. A DNS caching problem
- D. An incorrect test assertion
Correct answer: B. A healthy median with a bad p99 indicates tail-latency effects (GC pauses, lock contention, queueing) hitting a small fraction of requests.
In contract testing (e.g., consumer-driven contracts), what does the contract primarily protect against?
- A. Slow database queries in the provider
- B. Breaking API changes between a consumer and provider service ✓
- C. Memory leaks in the consumer
- D. UI rendering regressions
Correct answer: B. Consumer-driven contracts verify the provider still honors the request/response shape the consumer relies on, catching breaking API changes early.