Is 100% coverage required for safety-critical software?

Why

• Blast radiussafety-or-legal
• Change frequencyrarely
• Detectabilitynever
• Reversibilityimpossible
• Test costheavy

Yes, at the top safety levels the standard requires 100%, and rule R2 gives Test mandatory. The typical case is a team writing flight or spacecraft software under DO-178C or ECSS, asking about code its requirements-based tests have not reached. Blast radius is safety-or-legal and Reversibility is impossible, because a failure can injure a person. Detectability is never, since an unrun branch first runs in service; Change frequency is rarely, since a certified baseline changes only through change requests, and Test cost is heavy, because the last branches need the target rig. The framework does not set the figure: its limits leave that to your safety standard.

What breaks if you don't test

Unrun branches handle rare cases, such as two sensors that disagree, so the crew meets the failure the first time that case occurs in flight. A coverage report with unexplained gaps also fails DO-178C Table A-7 and ECSS-E-ST-40C clause 5.8.3.5, and the software is not accepted.

What you lose if you over-test

Tests written from the code to reach a line earn no credit: DO-248A, quoted in the NASA MC/DC tutorial, says structural testing does not meet the objective, because coverage must come from requirements-based tests. MC/DC on Level C code adds cases that no auditor asked for. And 100% MC/DC shows that the code matches its requirements, not that the requirements match the aircraft.

How to test

1. Look up the criterion for your level. DO-178C asks for statement coverage at Level C, adds decision coverage at Level B and MC/DC at Level A. ECSS-E-ST-40C asks for 100% statement and decision coverage in categories A and B, and MC/DC in A.
2. Measure coverage across unit, integration and system tests from the first test.
3. For each gap, find the cause that DO-178B section 6.4.4.3 lists: a missing test, a missing requirement, dead code (remove it) or deactivated code (analyse it).
4. Write each missing test from a requirement, never from the code.

MC/DC needs at least n + 1 cases for n conditions (NASA MC/DC tutorial). A simplified thrust reverser rule:

#include <assert.h>
#include <stdbool.h>

/* Requirement: unlock the reversers when armed and
   (wheels spun up or weight on wheels). */
bool unlock_reversers(bool armed, bool spun_up, bool on_ground) {
    return armed && (spun_up || on_ground);
}

/* 3 conditions, 4 cases. Each pair differs in one input and flips the result. */
void test_unlock_reversers(void) {
    assert(unlock_reversers(true,  true,  false) == true);   /* 1 */
    assert(unlock_reversers(false, true,  false) == false);  /* 2: armed, vs 1 */
    assert(unlock_reversers(true,  false, false) == false);  /* 3: spun_up, vs 1 */
    assert(unlock_reversers(true,  false, true)  == true);   /* 4: on_ground, vs 3 */
}

Cases 1 and 2 alone give 100% statement and decision coverage. If someone deletes || on_ground, only case 4 fails.

When the answer changes

• The hazard assessment puts the function at DO-178C Level D, which has no structural coverage objective.
• The software is a medical device: IEC 62304 names no figure, and FDA guidance asks for coverage that matches the risk.