An expected result is what a program should output for a given input, worked out from the requirement or by tracing the algorithm before it runs. It is the thing a test is compared against. If you skip this step, a wrong output can look reasonable.
This lesson follows designing test data and belongs to the validation, verification and testing module.
How do I work out an expected result?
Use a trace table. Write the variables as columns. Start with their initial values, then follow each line in order and record every change.
If a requirement is given in words, you can also reason directly from it. Either way, write the expected value down first.
Worked example
A fictional teacher counts how many of five test marks are a pass. The pass mark is 50 or more.
Total ← 0
FOR Count ← 1 TO 5
INPUT Mark
IF Mark >= 50 THEN
Total ← Total + 1
ENDIF
NEXT Count
OUTPUT TotalThe five marks entered are 62, 48, 50, 91, 49.
Step 1, set up the table with columns Count, Mark, Mark >= 50, Total. Start with Total = 0.
Step 2, trace each iteration.
| Count | Mark | Mark >= 50 | Total |
|---|---|---|---|
| (start) | 0 | ||
| 1 | 62 | TRUE | 1 |
| 2 | 48 | FALSE | 1 |
| 3 | 50 | TRUE | 2 |
| 4 | 91 | TRUE | 3 |
| 5 | 49 | FALSE | 3 |
Step 3, read the output. After the loop, OUTPUT Total gives 3.
Step 4, check against the requirement. Passing marks are 62, 50 and 91. That is three marks, so the code and the requirement agree.
The note in the table matters: row 3 has Mark 50, and >= makes it a pass. That boundary value is where predictions most often slip.
The mistake to watch for
Mistaken prediction: “The output is 2, because 50 is only a pass if the mark is above 50.”
The student read
>=as>.
The symbol >= means greater than or equal to, so 50 passes. The student’s table would show FALSE in row 3 and end at 2, which gives the wrong expected result. Slow down on comparison symbols and say them aloud: “greater than or equal to”.
After you write the prediction, you run the program. If it prints 3, the test passes. If it prints 2, you have found a fault in the code, because your prediction came from the requirement.
Check yourself
1. Trace this and state the output.
Sum ← 0
FOR N ← 1 TO 6
IF N MOD 2 = 0 THEN
Sum ← Sum + N
ENDIF
NEXT N
OUTPUT SumShow answer
N MOD 2 = 0 is TRUE for 2, 4 and 6. Sum goes 0, 2, 6, 12. The output is 12.
2. The marks 70, 30, 50 are entered into the pass-counting algorithm above with the loop changed to run three times. What is the expected output?
Show answer
70 passes, 30 does not, 50 passes. The output is 2.
3. A student predicts 5 for question 2 because “there are five marks”. What went wrong?
Show answer
They used the loop count from the original program and counted every mark, not only the passes. The question has three marks, and only two meet the condition Mark >= 50.
Where does this lead next?
Next, learn to spot a branch of the code that no test has run. You can practise tracing in the restricted pseudocode trace trainer, and the mixed practice set mixes tracing with test design.
If your traces break down in loops, that is something we work on in online one-to-one Computer Science tuition.