Seven misconceptions of MC/DC

If you’ve been following this blog, you’ll have seen a number of posts related to MC/DC (Modified Condition/Decision Coverage). DO-178B has driven its use in many aerospace programs, and now, with the introduction of ISO 26262, MC/DC is increasingly becoming relevant to automotive embedded systems. We’ve spent time participating in various discussion groups online, noticing that a number of misconceptions about MC/DC crop up quite regularly. In the first in a series of blog posts, we set out what MC/DC is and provide an outline of the seven frequently-encountered misconceptions about MC/DC.

What is MC/DC?

MC/DC measures your attempt to test your code. It is not an exhaustive testing approach, but aims to provide a practical alternative. Achieving 100% MC/DC gives you confidence that terms in Boolean expressions are significant in determining the outcome, and that the tests have exercised many paths through the code. It seems simple enough, but it's easily misunderstood.

The seven misconceptions of MC/DC

The misconceptions fall into three categories:

1. What does it mean to get 100% MC/DC?
   • Getting 100% MC/DC means you've got correct code;
   • Getting 100% MC/DC means your compiler compiled your code correctly;
   • Getting 100% MC/DC means you've tested 100% of your requirements.
2. How do you get to 100% MC/DC?
   • Once you've tested 100% of your requirements you should add the extra tests needed to achieve MC/DC.
3. How can you get round MC/DC?
   • You can get round MC/DC by restructuring your code;
   • You can get round MC/DC by assigning expression results to variables;
   • You can get round MC/DC by using bitwise operators.