MC/DC requires all of the below during testing:1
Independence of a condition is shown by proving that only one condition changes at a time.
MC/DC is used in avionics software development guidance DO-178B and DO-178C to ensure adequate testing of the most critical (Level A) software, which is defined as that software which could provide (or prevent failure of) continued safe flight and landing of an aircraft. It is also highly recommended for SIL 4 in part 3 Annex B of the basic safety publication2 and ASIL D in part 6 of automotive standard ISO 26262.3
Additionally, NASA requires 100% MC/DC coverage for any safety critical software component in Section 3.7.4 of NPR 7150.2D.4
It is a misunderstanding that by purely syntactic rearrangements of decisions (breaking them into several independently evaluated conditions using temporary variables, the values of which are then used in the decision) which do not change the semantics of a program can lower the difficulty of obtaining complete MC/DC coverage.5
This is because MC/DC is driven by the program syntax. However, this kind of "cheating" can be done to simplify expressions, not simply to avoid MC/DC complexities. For example, assignment of the number of days in a month (excluding leap years) could be achieved by using either a switch statement or by using a table with an enumeration value as an index. The number of tests required based on the source code could be considerably different depending upon the coverage required, although semantically we would want to test both approaches with a minimum number of tests.
Another example that could be considered as "cheating" to achieve higher MC/DC is:
if the definition of a decision is treated as if it is a boolean expression that changes the control flow of the program (the text in brackets in an 'if' statement) then one may think that Function B is likely to have higher MC/DC than Function A for a given set of test cases (easier to test because it needs less tests to achieve 100% MC/DC coverage), even though functionally both are the same.6
However, what is wrong in the previous statement is the definition of decision. A decision includes 'any' boolean expression, even for assignments to variables. In this case, the three assignments should be treated as a decision for MC/DC purposes and therefore the changed code needs exactly the same tests and number of tests to achieve MC/DC than the first one. Some code coverage tools do not use this strict interpretation of a decision and may produce false positives (reporting 100% code coverage when indeed this is not the case).
In 2002 Sergiy Vilkomir proposed reinforced condition/decision coverage (RC/DC) as a stronger version of the MC/DC coverage criterion that is suitable for safety-critical systems.78
Jonathan Bowen and his co-author analyzed several variants of MC/DC and RC/DC and concluded that at least some MC/DC variants have superior coverage over RC/DC.9
Hayhurst, Kelly; Veerhusen, Dan; Chilenski, John; Rierson, Leanna (May 2001). "A Practical Tutorial on Modified Condition/ Decision Coverage" (PDF). NASA. https://shemesh.larc.nasa.gov/fm/papers/Hayhurst-2001-tm210876-MCDC.pdf ↩
IEC 61508-3:2010 ↩
ISO 26262-2011 Part 6 Table 12 ↩
"NASA Software Engineering Requirements". NASA. https://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=7150&s=2D ↩
Rajan, Ajitha; Heimdahl, Mats; Whalen, Michael (March 2003). "The Effect of Program and Model Structure on MC⁄DC Test Adequacy Coverage" (PDF). {{cite journal}}: Cite journal requires |journal= (help) https://homepages.inf.ed.ac.uk/arajan/My-Pubs/tosem-main.pdf ↩
http://www.hbni.ac.in/phdthesis/engg/ENGG02201004005.pdf [bare URL PDF] http://www.hbni.ac.in/phdthesis/engg/ENGG02201004005.pdf ↩
Vilkomir, S.A.; Bowen, J.P. (2002). Reinforced condition/decision coverage (RC/DC): A new criterion for software testing. Lecture Notes in Computer Science. Vol. 2272. Springer-Verlag. pp. 291–308. doi:10.1007/3-540-45648-1_15. ISBN 978-3-540-43166-4. {{cite book}}: |journal= ignored (help) 978-3-540-43166-4 ↩
Vilkomir, S.A.; Bowen, J.P. (2006). "From MC/DC to RC/DC: formalization and analysis of control-flow testing criteria". Formal Aspects of Computing. 18 (1). Springer Nature: 42–62. doi:10.1007/s00165-005-0084-7. S2CID 10467796. /wiki/Sergiy_Vilkomir ↩
Kapoor, Kalpesh; Bowen, Jonathan P (2005). "A formal analysis of MCDC and RCDC test criteria". Software Testing, Verification and Reliability. 15 (1). Wiley Online Library: 21–40. doi:10.1002/stvr.306. S2CID 35276126. /wiki/Jonathan_Bowen ↩