Coverage Metric Dispute Before Sign-off
A team must sign off a release of a claims-processing application. The build has 84% statement coverage and 61% branch coverage from unit tests. The test manager wants to block release until branch coverage reaches 80%. The developers argue the metric is gamed and that integration tests cover the rest. Integration tests are manual and undocumented. A critical module, premium calculation, has 91% statement but only 44% branch coverage, with many compound conditions around discounts and eligibility. Two prior releases had defects in exactly that module. The release is tomorrow and the business sponsor is pressing.
1. Assess the coverage argument. Should the release be blocked on the 80% branch target?
Read the worked answer
The 80% branch target is a proxy, not a goal in itself. Blocking on a blanket number invites gaming, such as writing trivial tests to flip branches. The real signal is the premium calculation module: 44% branch coverage on compound discount and eligibility logic, with two prior defects there. That is a concentrated risk, and it deserves targeted attention regardless of the overall number.
A defensible position: do not block on the aggregate 80% figure, but do not sign off the premium module at 44% branch coverage without evidence. Require branch-level tests for the compound conditions (discount thresholds, eligibility combinations) and a documented risk assessment for any untested branches. The developers' claim that integration tests cover the rest is unverifiable because those tests are manual and undocumented. Unverifiable coverage claims cannot offset a measured gap. Ask for the specific integration scenarios and their outcomes; if they cannot be produced, treat the gap as open.
2. What would you require before sign-off, given the deadline pressure?
Read the worked answer
Require a short, focused set of conditions: (1) branch tests for the premium module's compound conditions, prioritized by business impact and prior defect history; (2) a written risk assessment listing untested branches and their potential consequences; (3) documented integration scenarios, even brief, so the claim is auditable; (4) a decision record signed by the sponsor accepting any residual risk. If the sponsor accepts risk, that is a business decision, but it must be explicit and recorded, not implied by silence.
On timing: the deadline is a constraint, not a reason to skip evidence. A half-day of targeted branch testing in the highest-risk module is feasible and proportionate. I would not trade that for a blanket push to 80% across the codebase, which spends effort where risk is lower. The metric should guide where to look, not replace judgement about what matters.