Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might h

Question

Options

• AYes
• BNo

• A
  31% (12)
• B
  69% (27)

Explanation

Option B (No) is correct because increasing code coverage measures how much of the source code is exercised by tests, but it does nothing to address intermittent test failures that are unrelated to source code or environment changes - these are typically "flaky tests" caused by issues like timing dependencies, race conditions, or external service instability.

The proper solution to minimize troubleshooting effort for flaky tests is to implement a retry mechanism (automatic test retries), which allows the pipeline to re-run failed tests automatically, reducing manual intervention and noise from non-deterministic failures.

Option A (Yes) is wrong because adding more code coverage would only add more tests to the suite, potentially introducing more flaky tests rather than resolving the intermittent failures already occurring.

Memory Tip: Think of it this way - "flaky tests need a retry, not more coverage." When a test fails randomly and the code/environment isn't the cause, you need resilience (retries), not more measurement (coverage). On the exam, watch for the keyword intermittent - it almost always points toward retry logic as the solution, not coverage, debugging, or refactoring.

No community discussion yet for this question.