Theory: Written-Response Practice
A good mechanic does not learn every car separately; they learn a handful of engine families and recognise which one is under the bonnet. Written exam questions in this course fall into eight families in the same way. Each family tests a different skill and expects a different answer shape. Once you can name the family, you know what the marker is looking for before you write a word.
A strong written answer, in every family, follows the method of 9.1: answer the command word immediately, state the course definition or principle, give the mechanism, connect it to the question, and close with a one-sentence conclusion. The families below are that method applied to eight recurring question types.
The Eight Families
| # | Family | What it tests | Expected answer shape |
|---|
| 1 | Definition & distinction | Knowing two related terms precisely enough to separate them | Definition of A, definition of B, the decisive difference, one shared example |
| 2 | Compare two approaches | Comparing alternatives under the same criteria, not listing unrelated facts | Shared purpose, how each works, strengths, limitations, when each is preferable |
| 3 | Explain a principle & its consequence | Moving from a named principle to the testing behaviour it requires | Principle, why it is true, what the tester must do, what it cannot guarantee |
| 4 | Explain a lifecycle or process | Order, transition and purpose of each stage | Starting state, ordered transitions, evidence for each transition, feedback loop, end condition |
| 5 | Apply a definition to a scenario | Classifying facts with a course definition and defending it | Concept name, matching facts, why a nearby concept fits less well, consequence |
| 6 | Justify a testing strategy | Recommending a technique from its strengths, limits and the scenario’s risks | Recommendation, two or more reasons, limitation, complementary technique |
| 7 | Explain why another test level is necessary | What only becomes testable once components are combined or the system exists | Limit of the earlier level, new risks, the right next level, independence |
| 8 | Evaluate & recommend a completion criterion | Choosing between Categories 1, 2 and 3 for a given organisation | Context, category choice, reason, limitation, combined recommendation |
The Procedure for Each Family, in Brief
- Definition & distinction: define the first term by its reference point or objective; define the second with the same structure; state the single difference that stops them being interchangeable; apply both to one example.
- Compare: state the shared goal; pick two to four dimensions; discuss both approaches under every dimension; end with when each is preferable rather than declaring one universally better.
- Principle & consequence: state the principle in one sentence; explain why it is true; describe what a tester must do because of it; say what that response still cannot guarantee.
- Lifecycle or process: name the starting state; describe each transition in order and the evidence that allows it; include any feedback or regression loop; say when the process stops.
- Apply a definition: paraphrase the criterion; match each important fact to it; rule out a nearby concept if confusion is likely; state the testing or management consequence.
- Justify a strategy: name the technique immediately; tie each reason to a fact in the scenario; admit the technique’s main limitation; name a complementary technique that covers it.
- Another test level: state what the earlier level establishes; state what it leaves untested; name the new risks; explain why the next level, or an independent perspective, is needed.
- Completion criterion: identify the test level and the evidence available; choose the category that fits that evidence; state its limitation; add a second category if one source of evidence is not enough; reject weak rules such as “stop at the deadline”.
How to write the answer: in families 1, 2 and 7 the marks sit in the contrast: the decisive difference, the same criteria for both sides, the risk the earlier level cannot see. A list of separate facts, however correct, leaves that contrast for the marker to supply, and the marker will not.
Common mistake: stopping at a label. “Black box first because of bias” names a reason without giving the mechanism. Always say how the reason works (seeing the code makes the tester think like the developer, who believes the program works) and what follows from it.
The model answers below are deliberately compact: each is the length that earns the marks, not the longest answer possible. Cover the solution, write your own answer, then compare the structure as well as the content.
Worked Examples
Exercise 1
Family 1: definition & distinction. Distinguish verification from validation and explain why both are necessary.
Show solution ↓Hide solution ↑
Solution
Verification asks whether the team built the product right: the software, or another artifact, is checked against its specification (the SRS or design document). Validation asks whether the team built the right product: its reference point is the user’s actual needs and intended use (see 1.2).
Both are necessary because the specification itself can be incomplete or wrong. A program can match a faulty SRS perfectly and pass verification while still failing the user. Bug definition 4 shows this: the software does not do something the specification does not mention but should (1.6). Checking the software against that specification always matches, so verification cannot expose the omission; only validation, which steps outside the specification to the user’s needs, can.
Conclusion: verification establishes conformance to the specified solution; validation establishes fitness for the user’s real problem, and neither can replace the other.
Exercise 2
Family 2: compare two approaches. Compare top-down and bottom-up integration testing.
Show solution ↓Hide solution ↑
Solution
Shared goal. Both integrate units that have already been unit-tested, step by step, so that interfaces and interactions can be tested (see 8.3).
How they work. Top-down starts with the main control module; missing lower modules are replaced by stubs, which are swapped one at a time for the real modules. Bottom-up starts with the lowest modules, combines them into clusters, and uses drivers to call them, supply test data and capture results; the drivers are replaced by real higher modules step by step.
Strengths. Top-down gives an executable program early and finds interface flaws in the upper levels early. Bottom-up gives better controllability and observability of the low-level modules.
Limitations. Top-down has poorer controllability and observability of low-level behaviour, and stubs are costly to write and maintain. Bottom-up produces an executable program only very late, and writing many drivers is expensive. (The two lists are mirror images.)
Conclusion: the choice depends on which risk needs early visibility: top-down favours an early view of the whole system and its upper interfaces, bottom-up favours direct control over the low-level units.
Exercise 3
Family 3: explain a principle and its consequence. Explain why exhaustive testing is impossible and how this changes test planning.
Show solution ↓Hide solution ↑
Solution
Principle. Exhaustive testing is impossible (Principle 2, see 1.5 and 2.1). The number of inputs, input sequences, internal paths, states and environment combinations grows far beyond any available time. Even a restricted calculator with two operands from 000 to 999 and four operators has 1,000×1,000×4=4,000,000 combinations, about 22 hours at 0.02 s each, before signs, decimals, invalid inputs and key sequences multiply it further. On the white-box side, loops and branches cause the same explosion of paths.
Consequence. Test planning must accept that only a sample can be tested, and that not all errors are equally important. The team estimates the risk (how often a failure happens × how much it costs), tests high-risk features first, and uses techniques that make each test count: equivalence partitioning, boundary value analysis and MC/DC.
Limit and conclusion: these choices reduce the remaining risk, but they cannot prove that no bugs remain; testing is planned around risk precisely because completeness is out of reach.
Exercise 4
Family 4: explain a lifecycle or process. Explain the red–green–refactor cycle in test-driven development.
Show solution ↓Hide solution ↑
Solution
Start. The cycle begins in green: all existing tests pass (see 8.4).
Green → red. The developer writes the smallest useful new test, and it must fail, for the intended reason. The failure proves the test can detect the missing behaviour.
Red → green. The developer writes the minimum production code that makes the new test, and every earlier test, pass. The system is green again.
Green → refactor → green. From green the developer may add the next failing test or refactor: improve the structure without changing observable behaviour. Because behaviour must not change, the whole regression suite must still pass; if refactoring breaks a test, the code is red again and must be repaired before any new functionality.
End condition and limit: the cycle repeats until the required behaviour is covered and the code is acceptably structured. Passing unit tests still does not replace acceptance testing or prove that the customer will accept the product (8.6).
Exercise 5
Family 5: apply a definition to a scenario. A developer adds an undocumented export feature because customers may find it useful. Is this a defect?
Show solution ↓Hide solution ↑
Solution
Yes. Under bug definition 3, software that does something the specification does not mention contains a defect (see 1.6). The fact that matches is “undocumented”: the specification contains no export feature, so the behaviour exceeds what was agreed.
The developer’s good intention does not authorise the extra behaviour. An unreviewed feature can bring security, privacy, compatibility, maintenance or usability consequences that nobody has examined or tested. It is not definition 4 (something missing that should be there), because here something extra is present.
Consequence: if the stakeholders want the feature, the team should update the requirements and specification first and then test it like any other requirement. Until then it is reported as a defect.
Exercise 6
Family 6: justify a testing strategy. Why is black box testing normally performed before white box testing?
Show solution ↓Hide solution ↑
Solution
Black box first. Black box tests are derived from the requirements and specification, without implementation knowledge shaping the first choice of tests (see 3.2). This happens because a tester who studies the code first starts to think like the developer, who is biased towards believing the program works, and unconsciously picks cases that confirm the developer’s logic while missing requirements that were misunderstood or never implemented.
White box second. Once the specification-based cases are done, white box testing uses the code to find statements, branches, conditions and paths the black box suite never exercised, and adds test cases for them. Its limitation is that it cannot reveal a requirement that is missing from the code altogether, which is exactly what the black box pass protects against.
Conclusion: the order removes implementation bias first and then uses structural knowledge to strengthen coverage.
Exercise 7
Family 7: explain why another test level is necessary. Explain why passing unit tests is not sufficient evidence that the complete system works.
Show solution ↓Hide solution ↑
Solution
What unit tests establish. Each component behaves correctly within its own boundary, often with stubs, drivers, a controlled initial state and direct observation (see 8.1–8.2). They do not show that the real components communicate correctly once combined.
New risks after combining. Interface and protocol mismatches, incompatible data formats, precision errors that grow as results pass from unit to unit (three units each 90% accurate give 0.93=0.729), timing and synchronisation failures, and contention for shared resources.
The next levels. Integration testing examines these interactions (8.3). Function testing then checks the externally specified functions, and system testing checks the complete product against its original functional and non-functional objectives. Independent testers or IV&V can catch assumptions the development team shares, at extra cost (7.4).
Conclusion: successful unit testing is necessary but cannot replace integration, function, system or acceptance testing.
Exercise 8
Family 8: evaluate and recommend a completion criterion. A new organisation has no historical defect database and must decide when to stop system testing. Recommend a completion approach.
Show solution ↓Hide solution ↑
Solution
Category 2 is weak here. It sets a stopping number from past projects’ statistics (7.2). The organisation has no reliable history, so any target would rest on an unsupported estimate: it might be impossible to reach or too low to give confidence.
Recommend Category 3. Record the cumulative number of bugs found at equal time intervals, calculate the slope of each interval, and stop at the greatest drop in the slope, the point where returns start to diminish sharply (7.3). It needs no history, only close monitoring of the current project.
Limitation and combination. A falling rate can also come from weak tests rather than from fewer remaining bugs, so combine the trend with Category 1 evidence wherever coverage can be measured, for example required MC/DC coverage for individual modules.
Conclusion: do not declare completion just because the schedule ran out or the existing tests stopped failing; base the decision on the current trend plus evidence that the planned techniques were applied thoroughly.
Exercise 9
Extra (family 1). Distinguish testing from debugging.
Show solution ↓Hide solution ↑
Solution
Testing is executing the software to show that bugs exist: it compares actual with expected results and reports a mismatch. Debugging starts from a known failure and locates its cause and fixes it (see 2.4).
Decisive difference: testing demonstrates that there is a bug; debugging finds where and why, and removes it. They are often done by different people: testers test, developers debug.
Example: a tester shows that pressing 7 then = displays −7 (testing). The developer traces the code, finds that the missing operator sends the calculation into the subtraction branch, and corrects it (debugging); afterwards regression tests are rerun to make sure the fix broke nothing else.
Conclusion: testing ends with a demonstrated failure, debugging ends with a removed cause; of the two halves of debugging, locating the cause is by far the harder one.
Exercise 10
Extra (family 5). In JUnit, a test of withdraw() stops with a NullPointerException because the Account object was never created in the set-up method. A second test reports expected 150 but was 140. Classify each result.
Show solution ↓Hide solution ↑
Solution
The criterion (see 8.1): a failure means the test ran normally and the actual result did not match the expected result, so the test found a bug; an error means the test could not finish because something crashed for a reason not caused by the test’s expected result.
NullPointerException → error. The test never reached its assertion; it crashed because the fixture was incomplete. Nothing is yet known about whether withdraw() is correct.expected 150 but was 140 → failure. The test ran to its assertion and the actual balance differed from the expected one: a bug in the code under test has been demonstrated.
Consequence: the error is fixed in the test set-up and the test rerun; the failure is reported as a bug.
Exercise 11
Extra (family 8). Evaluate the rule “stop testing when all the test cases pass”.
Show solution ↓Hide solution ↑
Solution
Strength. It is easy to state and to check: either the suite is green or it is not.
Limitation. It rewards the wrong thing. The goal of testing is to show bugs, not to pass (1.5). A rule that ends testing on a full pass pushes testers towards easy tests that do not find bugs; the weaker the suite, the sooner testing “finishes”. A pass also proves only that the selected inputs worked, never that no bugs remain.
Conclusion: it is not an acceptable completion criterion. Use one of the three categories instead (see 7.1): planned coverage at low levels (Category 1), targets from past statistics where history exists (Category 2), or the greatest drop in the bug-finding slope (Category 3).