Theory: How to Write Answers the Professor Likes
Think of a delivery driver who brings a beautiful pizza to the house that ordered sushi. The pizza is excellent, but the customer still pays nothing for it. Exam answers work the same way: across the whole course the professor saw students lose marks not because they did not know the topic, but because they answered a slightly different question. In the review class the professor collected the advice given throughout the course into six habits. This lesson explains each habit and the reason behind it, then adds a general method for any written answer.
The Six Habits
| # | Habit | One-line reason |
|---|
| 1 | Answer exactly what is asked | A true answer to a different question earns nothing. |
| 2 | “Why” → start with “This happens because…” | It forces a reason instead of a description. |
| 3 | Yes/no → write yes or no first | The marker should not have to dig for your verdict. |
| 4 | Discussion → two paragraphs | Principles first, then what they mean for the question. |
| 5 | Every test case has an expected output | Without it, there is nothing to compare against. |
| 6 | State your assumptions and show your work | The professor does not trust an answer whose route is invisible. |
Habit 1: answer exactly what is asked
Two moments from class show how easy it is to drift:
- Lecture 2 (2.3), “find the bug”. Groups reading the CalcEngine code were asked to find the bug. Several wrote the fix. A fix is useful work, but finding and fixing are different activities (testing shows a bug exists; debugging locates and fixes it, see 2.4), so the answer missed the question.
- Lecture 3 (3.1), “what should a tester assume?” Some students answered “we should try to break the program”. That is true, but it is the purpose of testing, not the assumption. The assumption the professor wanted is: not all errors are equally important, because not all features are equally important, so the tester uses risk analysis to look for the critical errors first.
Both answers were true statements, and both got no marks. Read the question twice, and if you are unsure, repeat the question’s key words inside your answer.
Habit 2: “why” questions start with “because”
Write “This happens because…” and make the words after because your real reason. A “why” question asks for a cause; without the anchor word, students tend to describe what happens instead.
Habit 3: yes/no questions start with the verdict
Do not make the marker guess your answer from a long paragraph. “No. Verification checks the software against the specification, so…” is the shape the professor wants: verdict, then justification.
Habit 4: discussion questions take two paragraphs
- Paragraph 1 states the principles: the foundation from the course that the question rests on.
- Paragraph 2 uses those principles to explain the meaning of the statement in the question.
The model is the “spiral of unattainable perfection” discussion (2.5), worked out in full as Q2e of the Mock Exam.
Habit 5: every test case has an expected output
A test case is an input plus an expected result. Without the expected result there is nothing to compare the actual result against, so you cannot tell whether the test passed. The idea appears again and again: expected results in 1.2, Myers’ first principle in 3.1, and the last objective of the triangle exercise in 6.1.
Habit 6: state assumptions and show your work
Many questions end with “State explicitly your assumption(s)”. Typical assumptions in this course are the 40/60 CLD/design split in a completion calculation (7.2), an E constraint between causes in a cause-effect graph (6.3), or whether rules form a chain or are independent. In MC/DC, mark your independence pairs with colours or shapes (3.5): the professor said that an answer whose working cannot be seen is not trusted, even if the final set is right.
Exam radar: definitions will be paraphrased in the exam. The professor will not write “build the thing right”; the question will describe the idea in other words. Learn the idea behind each term, not only its sentence.
A Method for Any Written Answer
The six habits tell you what to avoid. The following five steps give every written answer a backbone, whatever the topic:
- Answer the command word immediately: define, distinguish, compare, explain, justify, evaluate or apply.
- State the relevant course definition or principle accurately.
- Give the mechanism or reason. Do not stop at a label.
- Connect the mechanism to the scenario or consequence in the question.
- Finish with a one-sentence conclusion that answers the question directly.
It is the same idea as habits 2 and 4 written as a recipe: a claim, the course foundation, the reasoning, the application, and a closing sentence that lands back on the question.
Command Words
The first word of the question tells you the shape of the answer. Treat it like an order at a restaurant: “grilled” and “fried” use the same fish but produce different dishes.
| Command word | What the answer must contain |
|---|
| Define | The meaning, plus the feature that distinguishes the term from its neighbours. |
| Distinguish | Define both terms, then state the decisive difference. |
| Compare | Discuss both approaches under the same criteria. |
| Explain why | Claim, mechanism, consequence. |
| Justify | A recommendation plus reasons tied to the scenario’s facts. |
| Evaluate | A strength, a limitation, and a bounded conclusion. |
| Apply | Name the concept and show why the facts match it. |
How to write the answer: before writing a word, underline the command word and any limiter (“one advantage”, “for the module test”, “in JUnit”). Then check your finished answer against both: right shape, right scope.
Common mistake: writing everything you know about a topic. A “distinguish” question answered with two separate definitions and no stated difference, or a “compare” question that lists strengths of one approach and weaknesses of the other, loses the marks for the actual task.
Section 9.3 practises these command words across the eight families of written questions.
Worked Examples
Exercise 1
Question: “Read the CalcEngine code. Find the bug that occurs when the user presses 7 and then = without choosing an operator.”
Weak answer: “Add a check in the equals method so that, if no operator has been chosen, the display value is left unchanged.”
Explain why the answer loses marks, and rewrite it.
Show solution ↓Hide solution ↑
Solution
The question says find, so the answer must describe the bug: the input, what happens, and what should happen. The weak answer describes a fix, which is debugging work (see 2.4), not the question that was asked. It never even states the wrong behaviour.
Strong answer: “The bug: after pressing 7 and then = with no operator, the display shows −7 instead of 7. This happens because, with no operator stored, the calculation falls into the else branch, which computes the left operand (still 0) minus the display value 7, so the result is 0−7=−7.”
Exercise 2
Question: “Finding every error in a program is impossible. What should a tester assume, and what follows from it?”
Weak answer: “The tester should assume the program has bugs and try to break it.”
Rewrite the answer so it addresses the question.
Show solution ↓Hide solution ↑
Solution
“Try to break the program” is the purpose of testing, not the assumption the question asks about. The reasoning chain the professor wanted is:
- We cannot find all errors, so we will only find some of them.
- So we must choose which ones to look for.
- Errors are not equally important, because features are not equally important.
Strong answer: “The tester should assume that not all errors are equally important, because not all features are equally important (a wrong button colour is minor, sending money to the wrong account is a disaster). It follows that the tester uses risk analysis to find the most critical errors first: as many bugs as possible, in as little time as possible, as early as possible.”
Exercise 3
Question: “Why must each unit test run independently of the other unit tests?”
Weak answer: “Each test is run on its own and the tests can be executed in any order. JUnit runs them one after another.”
What is missing? Rewrite it using habit 2.
Show solution ↓Hide solution ↑
Solution
The weak answer describes what happens (tests run separately, in any order) but never gives a reason. A “why” question asks for a cause.
Strong answer: “This happens because a unit can leave a side effect, such as a changed shared variable, that a later test might rely on. If test B only works after test A has run, the result of B depends on the order of execution: B may pass or fail for reasons that have nothing to do with the code it tests, and a failure in A can hide or fake a bug in B. Independent tests can run in any order and each result points at one unit, so a failure can be trusted (see 8.1).”
Exercise 4
Question: “A test suite of 500 test cases passes completely. Does this prove the program has no bugs?”
Weak answer: “Testing is a process of executing a program to find errors. Many test cases were run, and they all passed, which is a good sign, but there are always limits to what tests can show, so it depends on the tests.”
Rewrite it using habit 3.
Show solution ↓Hide solution ↑
Solution
The weak answer never commits; the marker has to guess whether the student means yes or no.
Strong answer: “No. Testing can show that bugs are present but cannot prove they are absent (Principle 1, see 1.5). A pass only means the 500 selected inputs produced their expected results; exhaustive testing is impossible (Principle 2), so the untested inputs may still contain bugs. In fact, if the tests were designed to pass, a full pass says little at all, since the goal of testing is to show bugs, not to pass.”
Exercise 5
A student writes these test cases for the triangle program:
| Test | Input (a, b, c) |
|---|
| 1 | (3, 4, 5) |
| 2 | (5, 5, 8) |
| 3 | (2, 3, 5) |
Explain what is wrong and correct the table.
Show solution ↓Hide solution ↑
Solution
None of the tests has an expected output. Without one, the tester has nothing to compare the actual result with, so a test case is incomplete (see 1.2 and Myers’ first principle in 3.1).
| Test | Input (a, b, c) | Expected output |
|---|
| 1 | (3, 4, 5) | Scalene |
| 2 | (5, 5, 8) | Isosceles |
| 3 | (2, 3, 5) | Not a triangle, since 2+3=5 is not greater than 5 |
Check for test 3: the triangle inequality needs the two shorter sides to sum to more than the longest, and 2+3=5 fails it ✓.
Exercise 6
For each question, name the command word and say what the answer must contain.
(a) “Distinguish a stub from a driver.”
(b) “Evaluate the rule ‘stop testing when the deadline arrives’.”
(c) “Justify using MC/DC rather than multiple condition coverage for a flight-control decision with 6 conditions.”
(d) “A developer adds an undocumented export button. Apply the five definitions of a bug to this case.”
Show solution ↓Hide solution ↑
Solution
(a) Distinguish: define both terms and state the decisive difference. A stub stands in for a lower module that the unit under test calls; a driver stands in for a higher module that calls the unit under test. Decisive difference: the direction of the call (see 8.2).
(b) Evaluate: a strength, a limitation and a bounded conclusion. Strength: easy to apply and fits the schedule. Limitation: it says nothing about quality, since you could do almost nothing and still “finish” on time. Conclusion: it is not an acceptable completion criterion; use one of the three categories (see 7.1).
(c) Justify: a recommendation plus reasons tied to the scenario. Recommend MC/DC; with 6 conditions multiple condition coverage needs 26=64 tests, while MC/DC needs about n+1=7, and it still shows that every condition independently affects the outcome, so no condition can hide behind short-circuit masking.
(d) Apply: name the concept and show why the facts match it. This is bug definition 3: the software does something the specification does not mention. The fact that matches is “undocumented”: the specification has no export feature (see 1.6).
Exercise 7
“Testing shows the presence of bugs, not their absence.” Discuss.
Show solution ↓Hide solution ↑
Solution
Use the two-paragraph shape (habit 4).
Paragraph 1 (principles). This is the first of the seven testing principles (1.5). A test compares an actual result with an expected result for one chosen input; when they differ, a bug has been demonstrated. But exhaustive testing is impossible (Principle 2): even a small calculator has millions of input combinations, so any test suite runs only a tiny sample of the possible inputs.
Paragraph 2 (meaning). So a failing test is proof that a bug exists, while a passing suite proves only that the sampled inputs worked. Bugs can remain in everything that was not tried. This is why “the tests passed” never means “the software is correct”, why testers choose inputs by risk and by techniques that make each test count (EP, BVA, MC/DC), and why testing stops at a planned completion criterion rather than at “no bugs left”, a state that can never be confirmed.