Statement coverage (also called line coverage) will not detect which of the following types of problems in a program under test?

Introduction / Context:
Statement coverage is a basic white box testing metric that measures the percentage of executable statements in code that have been executed at least once during testing. While it is useful for identifying code that has never been exercised, it has limitations and cannot detect all types of defects. This question asks which problem statement coverage cannot identify, highlighting an important conceptual limitation of this metric.

Given Data / Assumptions:
- Statement coverage measures which existing code statements have been executed by test cases.
- Dead code refers to code that cannot be reached by any control flow path.
- Unused statements or branches refer to code that is present but never executed under the current test suite.
- Missing statements refer to logic that should be in the program according to requirements but has not been implemented at all.

Concept / Approach:
Statement coverage only considers the set of statements that exist in the source code. It checks whether each of these statements was executed at least once. It cannot reason about requirements that were never translated into code or about logic that should have been written but is missing. Therefore, defects arising from missing functionality are invisible to statement coverage. On the other hand, unreachable or unused code can result in coverage gaps that this metric can highlight, even if it does not fully explain why the code is unreachable.

Step-by-Step Solution:
1. Dead code and unused statements are present in the program but never executed; statement coverage will show that coverage for those lines is zero. 2. Unused branches correspond to decision outcomes that are never taken. While pure statement coverage may not distinguish branches, it will at least reveal that some statements on one branch are never executed. 3. Missing statements, by contrast, are not present in the code at all, so there are no lines for statement coverage to measure. 4. If a required validation step was never coded, statement coverage might still be 100 percent on the existing lines, yet the missing logic defect would remain undetected. 5. Therefore, the type of problem that statement coverage cannot address is functionality that is missing entirely from the code base.

Verification / Alternative check:
Imagine a simple requirement that a function must validate that an input value is nonnegative before proceeding. If the developer forgets to implement this check, there is no corresponding statement in the code. Even with exhaustive tests that execute all existing statements, statement coverage will report 100 percent. Yet the missing validation remains a serious defect. This example confirms that missing statements fall outside the scope of what statement coverage can detect, whereas unexecuted code lines would show up as coverage gaps.

Why Other Options Are Wrong:
Option A, dead code, can be suggested by statement coverage because lines that are never executed may indicate unreachable code, although further analysis is needed. Option B, unused statements, similarly will appear as unexecuted lines in coverage reports. Option D, unused branches, may require branch coverage for full insight, but statement coverage will still show that some statements associated with those branches are never run. Only option C, missing statements, describes defects that leave no trace in the code and therefore cannot be measured by statement coverage.

Common Pitfalls:
Teams sometimes equate high statement coverage with high overall test quality or complete verification of requirements. This is a misconception because coverage measures only how thoroughly existing code has been executed, not whether the code implements all required behaviour. Another pitfall is relying solely on structural metrics without complementing them with requirements based testing and reviews. This question emphasises that coverage metrics must be combined with other techniques to find missing functionality and design level defects.

Final Answer:
Statement coverage cannot identify code that was never written in the first place, so it will not detect missing statements that should have been implemented but are absent from the code.