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. 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]