9.2 Review: Completion Criteria, Decision Tables & MC/DC

Theory: Completion Criteria, Decision Tables & MC/DC

Before a long trip you do not reread the whole guidebook; you check the three routes you are most likely to take. In the review class the professor did exactly that and re-taught three topics with full worked examples: test completion criteria, cause-effect graphs with decision tables, and MC/DC. This page condenses those three, with the reason behind every step, then gives a map of the whole course and a rapid-reference sheet. The full lessons are 7.1–7.3, 6.3–6.4, and 3.5 with Lecture 4.

A. Test Completion Criteria (see 7.1–7.3)

The bug curve rises quickly, flattens, and never reaches the top (2.5). If you test until you “find everything”, you never stop. So a project fixes, before testing starts, a rule that says when testing is complete: the test completion criterion. The two rules everyone is tempted by are both bad: “stop when time runs out” (you could do nothing and still finish) and “stop when all tests pass” (it rewards easy tests that find nothing).

Category 2: the chain of the 10,000-statement example

Read the calculation as a chain where each link answers one “why”:

1. Total errors. 10,000 statements at about 5 errors per 100 statements: $10{,}000 \times 5 / 100 = 500$.
2. Kinds of error. The industry study in the slides: about 40% CLD (coding and logic design, small mistakes inside the code) and 60% design. So CLD $= 200$, design $= 300$. If the split is not given in the question, write it as your assumption.
3. Goals. Never 100% (unattainable perfection): 98% of CLD $= 196$, 95% of design $= 285$.
4. Share per level (from past projects), then target per level:

The module test finds 0% of design errors because a module test looks at one small unit; it is too low-level to see a design mistake. The columns add up to exactly the goals (98% and 95%), which is the check that the split is consistent.

Exam radar: “65% of what?” The professor asked this in class. It is 65% of the total CLD errors (200), not of all 500 errors, and not of the goal 196. Each design percentage is of the total design errors (300). In practice: stop the module test after finding 130 errors.

Category 3: the slope rule

Plot time (equal units, e.g. weeks) on the x-axis and the cumulative number of bugs found on the y-axis. The slope of each interval is the number of bugs found in that interval:

A high slope is good news: testing is paying off. The slope shrinks towards zero, but waiting for zero takes too long, so the rule is: stop at the greatest drop in the slope. Compute every slope, then each slope minus the one before it, and find the most negative difference.

The greatest drop is $15 - 35 = -20$, in the interval ending at week 4, so stop at week 4. If this comes in the exam the numbers are given; show every slope, every difference, and name the greatest drop clearly.

B. From Words to a Decision Table: dateFashion (see 6.3–6.4)

The specification: you and your date want a table at a restaurant. Each has a style from 0 to 10. If either of you has style 8 or more, the answer is 2 (yes), with the exception that if either of you has style 2 or less, the answer is 0 (no). Otherwise the answer is 1 (maybe).

The professor’s most important tip: reading a cause-effect graph straight out of the words is hard. Turn the words into the simplest possible code first; the conditions of the if statements become the causes and the return values become the effects. Keep the code simple, because a decision table cannot handle complex statements well.

int dateFashion(int you, int date) {
    if (you <= 2 || date <= 2)       return 0;   // effect 70: no (the exception wins)
    else if (you >= 8 || date >= 8)  return 2;   // effect 72: yes
    else                             return 1;   // effect 71: maybe
}

The “2 or less” check comes first because “with the exception” means that rule beats everything, even a very stylish partner.

• Causes: 1 = you <= 2, 2 = you >= 8, 3 = date <= 2, 4 = date >= 8.
• Effects: 70 = no (0), 71 = maybe (1), 72 = yes (2).

Now write the logic, remembering one rule: else = NOT of everything before it.

• 70 = 1 || 3
• 72 = (1 || 3)' && (2 || 4), because an else if only runs when the first if was false.
• 71 = (1 || 3)' && (2 || 4)', because the else runs only when the if and the else if were both false.

To reach MAYBE you must pass two “no” answers, so the maybe rule needs both NOTs. With only the first NOT, (1 || 3)' && (2 || 4) is exactly the yes rule, so maybe and yes would collide.

Exam radar: the professor singled out this rule after the review class: maybe = (1 || 3)' && (2 || 4)', which means all four causes false. Dropping the second NOT is the classic slip, and a rule the professor goes out of the way to stress is a strong sign it will be tested.

In the graph, two OR nodes group the causes (1 with 3, 2 with 4); NOT lines lead from the “no” OR node into the AND nodes for yes and maybe, and a second NOT leads from the “8 or more” OR node into maybe.

Finally, the decision table. All entries in one rule (one column) are joined by AND, so an OR cannot fit in one column: every OR splits into separate rules. Conditions that do not matter in a rule get an X.

The “no” OR becomes T1 and T2; the “yes” OR becomes T3 and T4; maybe is a single AND, so a single rule T5. The table gives the correct answer for every one of the $11 \times 11 = 121$ possible inputs.

C. MC/DC Once More (see 3.5 and Lecture 4)

The professor ended the review by saying that MC/DC can very often be expected in the exam.

Why it exists

Think of checking a team of guards by asking each one to do their job alone, while everyone else stands still. The cheap coverages (decision, condition, decision/condition) are fast but let bugs hide because of the short circuit: in A && B, if A is false Java never evaluates B, so a mistake in B stays invisible (A masks B). Multiple condition coverage fixes that by trying every combination, but that is $2^n$ tests and explodes. MC/DC is the sweet middle, the professor’s “optimal point between cost and strength”: for each condition it shows two tests that differ only in that condition and give different decisions. Since the other conditions stay fixed, nothing can hide, and it needs only about $n + 1$ tests.

Exam radar: MC/DC requires each condition to be shown to independently affect the outcome of the decision. A minimum MC/DC test set has $n + 1$ tests and can never be smaller. ($2n$ is a known upper limit; the course focuses on $n + 1$.)

The five steps, each with its reason

Checking a set someone gives you

Ask two questions in this order:

1. Does every extended column contain a complete pair inside the set? If not, it is not an MC/DC test set, whatever its size.
2. Does it have exactly $n + 1$ rows? If yes, it is a minimum test set; if more, it is a test set but not minimum.

This was the trap in the past exam question (4.3): the given set had exactly $n + 1$ rows, so it looked right, but one column had no pair. Pairs first, size second; the size alone never proves anything.

Quick reference: results to know

The Course Map

If a topic is not on this map, it was not taught in CSC312.

Rapid Reference

Core formulas

Final checks by question family

Course-specific traps

Common mistake: in a Category 3 question, picking the interval with the smallest slope. The rule asks for the greatest drop between neighbouring slopes, which usually comes earlier.

Worked Examples

int ticket(int age, boolean staff, boolean student) {
    if (age < 3 || staff)            return 0;   // E1: free
    else if (student || age >= 65)   return 1;   // E2: reduced
    else                             return 2;   // E3: full
}