Talk:Modified condition/decision coverage

Computing Stub‑class

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
Stub	This article has been rated as Stub-class on Wikipedia's content assessment scale.
???	This article has not yet received a rating on the project's importance scale.
	This article has been automatically rated by a bot or other tool as Stub-class because it uses a stub template. Please ensure the assessment is correct before removing the `\|auto=` parameter.

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]