What is MC/DC Coverage? A Visual Explanation with a Real-World Example

MC/DC stands for Modified Condition/Decision Coverage.

The basic idea: it is not enough to see that a decision in the code was true once and false once. MC/DC wants proof that every single condition inside the decision can change the result on its own. Why that matters is easiest to show with the following example.

A decision worth getting right

Consider a (simplified) airbag controller:

if (crash_detected && (frontal_impact || side_impact)) {
    deploy_airbag();
}

This is a typical plausibility check. The central accelerometer reacts to any strong deceleration – also to a rear impact or a hard pothole hit. In those cases the front airbag must not fire. So a second, direction-specific sensor has to confirm the crash first.

Which leads to the testing question: how do we prove that each of these three inputs really works?

The trap: 100% branch coverage, untested airbag

The first idea is simple: run the tests and look at the coverage report. Branch coverage only asks that the decision was seen as true and as false. So two tests are enough – one frontal crash for the true branch, one normal drive without a crash for the false branch.

The tool does not lie. Both outcomes of the decision were really observed. But side_impact was false the whole time and never changed the result. If its signal path is miswired or dead, no test will notice it. The report still says 100%. The problem stays hidden until a real side crash happens. This blind spot is the reason why MC/DC exists.

The fix: MC/DC in one table

For each condition, MC/DC asks for a test pair: two tests where only this one condition changes and the result of the decision flips.

Compare this to the branch coverage tests, the two branch tests would never fill this table. No pair of them lets side_impact flip the result. That is the whole point of MC/DC – a test suite with a dead sensor path cannot reach 100%. And we only need four tests for it, not eight.

So MC/DC takes the impact of all variables into consideration:

Where MC/DC sits: the coverage ladder

Testing all combinations (MCC) needs 2ⁿ tests. With 8 conditions that is already 256 – not realistic for a full code base. Branch coverage is cheap, as shown before, too weak. MC/DC sits in between: n + 1 tests, and every condition still has to prove that it works. This balance is the reason the safety standards motivate it.

Which standards require MC/DC?

Historically, MC/DC originated in avionics: it was first defined in DO-178B (1992) and carried forward into DO-178C. The aviation authorities needed a criterion that was strong enough for Level A software but still practical for real code. The other safety standards later adopted the same logic.

Standard	Domain	MC/DC applies at
DO-178C	Avionics	Required for Level A (catastrophic failure condition)
ISO 26262	Automotive	Highly recommended for ASIL D (unit level)
IEC 61508	Industrial	Highly recommended for SIL 4
EN 50128 / EN 50716	Rail	Highly recommended for SIL 3/4 (recommended for SIL 1/2)

What you need in practice

Nobody checks truth tables by hand in a real project. What you need in practice:

• A tool that really measures MC/DC – not only statement or branch coverage. It has to observe every single condition inside a decision.
• Gap reporting – the tool must show which cases your tests already cover, and which cases still have to be exercised to reach 100% MC/DC. Without this, closing the last gaps is guesswork.
• Coverage on the real target – measured while the integration and system tests run on the actual hardware. Then the evidence describes the software you ship.
• Reports for certification – coverage evidence across test levels and test runs, in a form an auditor can follow.