Talk:Modified condition/decision coverage

This article mixes the DO-178B coverage requirements and the test coverage criteria

This article mixes the DO-178B coverage requirements and the test coverage criteria. For example the Decision Coverage does not explicitly say that every point of entry and exit in the program must be invoked at least once. It only says Every decision in the program has taken all possible outcomes at least once. The first part could not be satisfied automatically (think of a function, procedure or method free of any decision node) but still the coverage criterion does not include it. Same for the mc/dc where it is about how all condition in a decision must have the possibility to act on the decision outcome.

I would like to add that "It is a form of exhaustive testing" is completely wrong in that exhaustive testing is just that. Its like saying its a "form of infinity". Infinity has no forms...its infinity or not. Look I went to 1...a form of infinity. Doesn't quite make sense does it.

One must define the difference between a condition and a decision. A condition is what drives a decision. The comparisons of the variables are the conditions. The path it takes is the decision.

Modified condition means that you use the boundary points of a condition and not an exhaustive case. Specifically NOT exhaustive. Nothing close to exhaustive. (Come here horse!..whap whap whap.) OK lets look at an example:

if (altitude < 3000)

Now an exhaustive test inputs values for the entire range of altitude. This obviously isn't realistic to do, so we modify our inputs to be just 2999, 3000, and 3001. One could input 2999 and 3000 and satisfy the condition, but usually companies want the structure of the low level code verified to match the high level code. By adding the 3001 value we can tell the < is a less than and not a not.

The below shows the problem of using just the minimal cases:

2999 < 3000 T 3000 < 3000 F

2999 != 3000 T 3000 != 3000 F

Our test results are the same so we don't know if < really exists in the code. Adding the 3001 input to the above two makes it clear:

3001 < 3000 F 3001 != 3000 T

Further I would like to see these articles dumbed down so the common man can understand them. Please avoid industry terms and non-common words.

That is my 55.627 cents in the form of a dollar. What year am I? —Preceding unsigned comment added by 64.91.67.29 (talk) 19:04, 6 August 2009 (UTC)

Should this article be merged to Code_coverage? Mr1278 (talk) 12:40, 19 October 2009 (UTC)

I am not really sure MC/DC is a form of exhaustive testing. i.e. it is not exhaustive testing. I added a link to a tutorial from NASA on this. Perhaps someone can condense information from the tutorial and add it here. Jabraham mw (talk) 15:03, 24 September 2010 (UTC)

Criticism?

The criticism paragraph makes no sense. The point of requiring MC/DC coverage is to expose subexpressions and variables that have no effect on the outcome of an expression. Breaking complex expressions into simple ones and using temporary variables isn't a cheat, it's a well-regarded means of making the logic less complex and more testable and debuggable, and will allow a programmer to redesign it to be correct, since a masked condition that has no effect on the overall expression is an error, and as dead code is not allowed to fly. The resulting test will be the same, since MC/DC effectively requires the same toggling of conditions and intermediate values whether the overall logic of the expression is contained on one line of boolean math or sprinkled throughout the program and propagated in local or global variables. 68.2.235.85 (talk) 00:12, 15 January 2016 (UTC)

I think I get it now. The cite for the criticism refers to a powerpoint presentation that has a serious error in it. In the first example where it reduces from 6 cases to 4, it makes c3 no longer independent of c1 and c2. Correctly done it would have had 5 cases in the end, with one more kept to toggle c3 while holding both c1 and c2 constant. That mistake invalidates the reference's entire conclusion, and therefore the basis for the criticism. 68.2.235.85 (talk) 03:27, 15 January 2016 (UTC)

Additionally Modified Condition/Decision Coverage doesn't claim test completes $(n+1)$ test cases per $n$ conditions, multiple condition coverage does.$2^{n}$, see Kelly J. Hayhurst et al. (2001). A Practical Tutorial on Modified Condition/Decision Coverage, p. 8, section 2.3.1, NASA, Hampton, Virginia. The MCDC could be described due to confinement. — Preceding unsigned comment added by Jbloeme (talk • contribs) 11:47, 3 January 2018 (UTC)

The example in the powerpoint presentation cited (http://se.inf.ethz.ch/old/teaching/2009-S/0276/slides/fiva.pdf) is identical to the example given in NASA's "A Practical Tutorial on Modified Condition/Decision Coverage" (https://shemesh.larc.nasa.gov/fm/papers/Hayhurst-2001-tm210876-MCDC.pdf), page 19. The reasoning is also copied verbatim (d1 is A, c1 is B, c2 is C, c3 is D) - and states that indeed changing the structure of the code can reduce the testcases required to satisfy MCDC. (I agree that this section of the wiki is horribly worded, I suggest rewriting it to reference NASA's paper.) TamaMcGlinn (talk) 14:01, 24 December 2019 (UTC)TamaMcGlinn

Reinforced condition decision coverage

I have taught MCDC at a large public university for the last 5 years and used it in the industry for a number of years.

I have never seen a definitive paper proving that RCDC is better than MCDC. Studying the Lau/Yu fault taxonomy and applying that single fault failure taxonomy to RCDC shows that it is in fact worse than MCDC for detecting single fault failures (the kinds that human programmers have the highest probability of making).

Dr Vilkomar proposed RCDC to "demonstrate that [SIC] each condition in a decision has been shown to independently keep the decision’s outcome... The idea that testing of the 'false actuation' (operation without demand) type of failures. This could make this criterion insufficient for many safety-critical applications.The false actuation of a system could be invoked by a software error in situations when changing a condition should not imply changing a decision." This is the intent of RCDC. But as I have already pointed out coverage from RCDC for the typical kinds of mistakes that humans make is worse than MCDC.

My own research shows that with these single fault failures (again the types that humans typically make) MCDC and the consequent technical review of the product containing the logical expression (either code or requirements) have a combined detection rate of 97% or higher of being able to detect these single fault failures. RCDC can be significantly worse. Thus I am deleting the reference to RCDC as there are many such MCDC variants and there is no point in singling out one of them especially one that has worse fault detection. — Preceding unsigned comment added by Dr JohnHRobb (talk • contribs) 14:49, 7 March 2020 (UTC)

As an academic you should understand that your own personal research won't suffice. If you contest the claim, you must do it properly by stating that the criteria may not be stronger, and cite a source that says as much Thepenguin9 (talk) 14:59, 7 March 2020 (UTC)

Fair enough. Table 2 in the following paper shows that RCDC is not only not superior to MCDC but inferior to several kinds of MCDC criteria - for example Unique Cause Strong MCDC (UCMS) or Masking. Kapoor, Kalpesh & Bowen, Jonathan. (2005). A formal analysis of MCDC and RCDC test criteria. Softw. Test., Verif. Reliab.. 15. 21-40. 10.1002/stvr.306. Therefore the claim is false and should be removed. Dr JohnHRobb (talk) 12:46, 20 March 2020 (UTC)— Preceding unsigned comment added by Dr JohnHRobb (talk • contribs) 12:42, 20 March 2020 (UTC)

Then please add to the article stating how this paper refutes it. But as far as I can see, there are two opposing papers and both have a spot on the page. Thepenguin9 (talk) 15:42, 26 March 2020 (UTC)