Mock Exam

$n = 3$ conditions, so $2^3 = 8$ rows. Standard order: every column starts with F, and the last variable (C) changes every row.

Result column, using masking: $Z = (\ldots) \land C$, so every row with C = F is F (rows 1, 3, 5, 7). For the rows with C = T, Z equals $A \lor B$, which is F only when both are F (row 2).

Extended columns: for each condition, compare the two rows that differ only in that condition; if Z changes, write the partner’s row number.

Checking the empty cells: A between rows 1–5, 3–7 (both F) and 4–8 (both T) gives no change; B between rows 1–3, 5–7 (both F) and 6–8 (both T) gives no change; C between rows 1–2 gives F both times.

Independence pairs: A $\{2, 6\}$; B $\{2, 4\}$; C $\{3, 4\}, \{5, 6\}, \{7, 8\}$.

First translate the values into rows: $(F,F,T)$ = row 2, $(F,T,T)$ = row 4, $(T,F,T)$ = row 6, $(T,T,T)$ = row 8. The proposed set is rows $\{2, 4, 6, 8\}$.

Pairs first:

• A: pair $\{2, 6\}$ is inside the set ✓.
• B: pair $\{2, 4\}$ is inside the set ✓.
• C: C = T in every proposed row, so no two rows differ in C. None of $\{3,4\}$, $\{5,6\}$, $\{7,8\}$ is complete ✗.

No. The set does not show that C independently affects Z, so it is not an MC/DC test set. It has exactly $n + 1 = 4$ rows, but the size proves nothing until every column has a complete pair.

Start with the columns that have the fewest pairs, because they leave no choice. A has only $\{2, 6\}$ and B has only $\{2, 4\}$, so rows 2, 4 and 6 are forced (row 2 is shared: overlap).

That is 3 rows; $n + 1 = 4$, so exactly one row may be added, and it must complete a C pair with a row already chosen:

• $\{3, 4\}$: add row 3 (row 4 is already in) ✓
• $\{5, 6\}$: add row 5 (row 6 is already in) ✓
• $\{7, 8\}$: needs two new rows, which would make 5 ✗

Check $\{2,3,4,6\}$: A $\{2,6\}$, B $\{2,4\}$, C $\{3,4\}$ ✓. Check $\{2,4,5,6\}$: A $\{2,6\}$, B $\{2,4\}$, C $\{5,6\}$ ✓.

The minimum MC/DC test sets are $\{2, 3, 4, 6\}$ and $\{2, 4, 5, 6\}$.

At least $n + 1$ test cases, and never fewer. Each of the $n$ conditions needs its own independence pair. Pairs may share rows (overlap), which is how the set stays small, but $n$ pairs always involve at least $n + 1$ distinct rows. Here $n = 3$, so 4 tests, as found in Q1c. If no selection of $n + 1$ rows works, try $n + 2$, then $n + 3$.

No. This is bug definition 4 (see 1.6). Verification checks the software against the specification. Here the specification itself is missing the requirement, so the software matches it and verification passes; comparing the software with a flawed specification can never reveal what the specification left out. Only validation, which checks against the user’s real needs, can detect it.

This happens because seeing the code makes the tester think like the developer, and the developer is biased towards believing the program works. A tester who reads the code first tends to choose tests that follow the code’s own logic and miss requirements that were misunderstood or never implemented. Testing black box first, from the specification, avoids this bias; white box testing then adds test cases for the statements, branches and conditions the black box tests did not reach (see 3.2).

• A failure: the test ran normally, but the actual result did not match the expected result, so the test found a bug. Example: assertEquals(150, balance) reports expected 150 but was 140.
• An error: the test could not finish because of an unexpected problem not caused by the test case’s expected result, for example a NullPointerException or a missing file.

Decisive difference: a failure is a wrong answer from code that ran; an error is a crash that stopped the test before it could judge the answer (see 8.1).

• Advantage: an executable program is available early, so interface flaws in the upper levels are found early.
• Disadvantage: controllability and observability of the lower levels are poorer, and the stubs that replace missing lower modules are costly to write and maintain.

(See 8.3; top-down pairs with stubs, bottom-up with drivers, and their good and bad points are mirror images.)

Paragraph 1 (principles). Testing can show that bugs exist, but it cannot prove that there are none (Principle 1), and exhaustive testing is impossible (Principle 2): even a restricted calculator has millions of input combinations. When we test, the number of bugs found rises steeply at first and then flattens; after the knee, at roughly 50–70% of the bugs that will ever be found, each new bug costs much more effort, and the curve never reaches the total.

Paragraph 2 (meaning). So “unattainable perfection” does not mean perfect software; it means the goal of showing every bug, which cannot be reached. A tester who chases that goal is caught in a spiral: more and more effort for fewer and fewer bugs, while time and budget run out for more important work. The better course is to test by risk, find the important bugs early, stop at a completion criterion planned in advance (Lecture 7), and accept the risk that remains.