DoAssignment study guide

B4.4 · Compare expected and actual results in a test plan

Learn to compare expected and actual results in a test plan through clear examples and targeted practice.

Ontario Grade 11 Computer Science

Software Development

Using a test plan to decide whether a program behaves as intended

A test plan lists inputs to try and the results a program is supposed to produce. For each test, compare that expected result with the actual result recorded when the program is tested. Matching results mean the test passes; different results mean it fails and the mismatch needs attention. This lesson focuses on making that comparison accurately. Any actual results shown below are supplied as example test records, not results produced by running the displayed code.

What you will learn

Explain the difference between an expected result and an actual result.
Compare the two results for each test in a test plan.
Record whether each test passes or fails and describe a mismatch clearly.

What the comparison tells you

Before testing, decide what result should occur for a particular input. This is the expected result. It should come from the program’s stated requirements or instructions, rather than from a guess about what the code might do. After someone tests the program, record what it actually displayed or returned. This is the actual result.

A test plan brings these details together so that a tester can check each case consistently. A basic row includes a test description, input, expected result, actual result, and a comparison such as Pass or Fail. If the program’s result does not match what was expected, record the difference specifically. For example, write “expected 8, actual 7,” rather than only “wrong.”

A pass means the results match for that test case. It does not prove that every possible input has been tested or that the whole program is free from problems. A fail identifies a particular case where the observed behaviour differs from the required behaviour.

Expected result: what the requirement says should happen.
Actual result: what the test record says happened.
Compare corresponding results, then mark Pass or Fail.

A careful comparison process

First, identify what the test is checking and confirm its input. Then work out the expected result from the requirement. For a short program, you can trace the stated input through the instructions to predict the result; this prediction is not the same as running the program. During testing, the tester records the actual result. Finally, compare the two using the same meaning and format.

Pay attention to what is being compared. If a requirement calls for the number of items, compare the recorded number—not an unrelated message. If the expected output is a whole line of text, check the complete line, including important words and values. Do not call two results a match merely because part of them looks similar.

When results differ, keep the test input and both results in the plan. A clear record helps someone understand which case needs follow-up. Do not silently change the expected result just to match the actual result. Check the requirement first: if the expected result was written incorrectly, correct it based on the requirement and make the reason clear.

Base expectations on requirements, not on observed output.
Compare the same result item in the same test case.
Keep mismatches visible and precise.

Reading a small test plan

The examples use short Python 3 snippets to make the expected results easy to trace. Python uses zero-based indexes for lists, but the examples do not require list indexing. A classroom may use a different programming language, so its syntax and display format may differ.

For each snippet, the inputs are stated, and the expected result is derived by following the shown instructions. Any actual result is explicitly described as a hypothetical result already recorded in a test plan. That distinction matters: tracing lets us predict; only a test observation supplies an actual result.

A test plan is useful when it makes the comparison easy to verify. Include enough detail to connect each actual result to its input. If a case fails, report both values and the specific difference rather than replacing the record with a vague comment.

Trace the code to derive an expected result; do not label a prediction as actual.
An actual result must come from a recorded test observation.
Record enough detail to connect each result to its input.

Using the comparison to report a result

After comparing a row, label it Pass or Fail. For a pass, the expected and actual results agree. For a fail, state exactly how they differ. In a group test, each person should be able to read the row and understand the outcome without guessing which input or output the note refers to.

The point is not to make every case pass by changing the record. The point is to compare faithfully. A failed comparison is useful information: it shows that the observed behaviour in that test case did not meet the expectation. Keep the original input, expectation, and observation together so the difference can be reviewed.

Use Pass only when the recorded results match.
For a failure, give the expected result and the actual result.
Keep the test record tied to the requirement being checked.

Sample test plan comparison

Test input or case	Expected result	Recorded actual result	Comparison
Study: 25 min; break: 5 min	30 min	30 min	Pass
Available: 12; used: 4	8 points	9 points	Fail: expected 8, actual 9
Name: Mira	Welcome, Mira!	Welcome Mira!	Fail: comma missing

Worked example

A matching result

Requirement: a program should return the number of minutes after adding a break to a study period. Input: 25 study minutes and a 5-minute break. The test plan records an actual result of 30. Compare the results.

Python 3

def total_minutes(study, break_time):
    return study + break_time

print(total_minutes(25, 5))

Identify the inputs
The two inputs are 25 study minutes and a 5-minute break. The requirement says the program adds these durations.
Derive the expected result
Adding the stated durations gives an expected result of 30 minutes. This is a prediction from the requirement and input, not an actual program run.
$25 + 5 = 30$
Compare the recorded result
The test plan records an actual result of 30 minutes. Because it matches the expected result of 30 minutes, mark this test Pass.
$30 = 30$

Answer: Expected result: 30 minutes. Recorded actual result: 30 minutes. Comparison: Pass.

Check: The result passes because the expected and recorded actual values match.

Worked example

A different result

Requirement: a program should report the number of points remaining after subtracting points used. Input: 12 points available and 4 points used. The test plan records an actual result of 9. Compare the results and report the mismatch.

Python 3

def remaining_points(available, used):
    return available - used

print(remaining_points(12, 4))

Identify the inputs
The test uses 12 points available and 4 points used. The requirement says to subtract the used points from the available points.
Derive the expected result
Following the requirement, 4 is subtracted from 12. The expected result is 8 points remaining.
$12 - 4 = 8$
Compare and report
The recorded actual result is 9, not 8. The values differ, so mark the test Fail and preserve the specific comparison: expected 8, actual 9.
$8 \ne 9$

Answer: Expected result: 8 points. Recorded actual result: 9 points. Comparison: Fail; the actual result is one point greater than expected.

Check: This is a failure because the recorded result does not match the result required for the given inputs.

Worked example

Comparing a text result

Requirement: when the name is Mira, the program should display the greeting “Welcome, Mira!”. Input: Mira. The test plan records the actual text “Welcome Mira!”. Compare the complete expected and actual messages.

Python 3

name = "Mira"
print("Welcome, " + name + "!")

Identify the input and required message
The input is the name Mira. The requirement gives the exact message, including its punctuation: “Welcome, Mira!”.
Trace the displayed text
The Python 3 statement combines the fixed text “Welcome, ” with the input name and an exclamation mark. This gives the expected message “Welcome, Mira!”. The comma and space are part of the expected text.
Compare the full messages
The recorded actual message is “Welcome Mira!”. It has no comma after “Welcome”, so the messages do not match. Mark the test Fail and note the punctuation difference.

Answer: Expected result: “Welcome, Mira!”. Recorded actual result: “Welcome Mira!”. Comparison: Fail because the comma is missing from the actual message.

Check: Compare the complete text, not just the shared words. The missing comma makes the actual message different from the stated expectation.

Common mistakes and how to avoid them

Calling a traced prediction an actual result.

Correction: Tracing can establish an expected result. Use actual result only for what the tester recorded during testing.

Marking a test as Pass because the results are close or mostly alike.

Correction: Compare the specified results as required. If a value or required part of a message differs, record a failure.

Writing only “wrong” when expected and actual results differ.

Correction: State both results and the difference, such as “expected 8, actual 9.”

Changing the expected result to match the actual result without checking the requirement.

Correction: Keep the expectation grounded in the requirement. Correct it only if the requirement shows the original expectation was mistaken.

Lesson summary

A test plan records what should happen and what a test actually recorded.
Derive the expected result from the requirement and the stated input.
Compare corresponding results and mark each case Pass or Fail.
For a failure, record the mismatch specifically; do not confuse a prediction with an observation.

Check your understanding

Question 1

A requirement says a program should display 14 for a particular input. The test plan records 14. What comparison should be recorded?

Pass, because the expected and actual results match.
Fail, because every test result needs to be different.
Pass only if another input also displays 14.
Fail, because the expected result should be replaced by the actual result.

Show answer and explanation

Pass, because the expected and actual results match.

For this test case, the expected result and recorded actual result are both 14, so they match and the case passes.

Question 2

The expected text is “Ready!” and the recorded actual text is “Ready”. What is the best test-plan note?

Pass, because the words are nearly the same.
Fail: expected “Ready!”, actual “Ready”; the exclamation mark is missing.
Pass, because punctuation is never part of text results.
Fail, but remove the expected result from the plan.

Show answer and explanation

Fail: expected “Ready!”, actual “Ready”; the exclamation mark is missing.

The complete messages differ because the actual result lacks the required exclamation mark. Record both messages and the specific difference.

Question 3

You trace a short program by hand and predict that it will display 6. What can you call 6 in the test plan before testing?

The actual result, because tracing proves what the program displayed.
The expected result, if it follows from the requirement and input.
A Pass, even if no actual result is recorded.
The actual result only if the code is written in Python.

Show answer and explanation

The expected result, if it follows from the requirement and input.

A hand trace supports a predicted expected result. The actual result must come from a recorded test observation.

Key terms

Test plan: A record of test cases, including inputs, expected results, actual results, and their comparisons.
Expected result: The result that should occur for a test input, based on the stated requirement.
Actual result: The result recorded when a test is carried out.
Pass: A test comparison in which the actual result matches the expected result.
Fail: A test comparison in which the actual result differs from the expected result.

Continue through ICS3U

View the complete ICS3U Ontario Grade 11 Computer Science curriculum and lessons

About this lesson and its review

Published by DoAssignment. This reviewed lesson follows Ontario Grade 11 Computer Science (ICS3U), expectation B4.4. It is a study resource, not an official curriculum publication.

Before publication, content is checked for structure, mathematical or chemical notation, calculations, course boundaries, and readability. Errors can still occur, so corrections are welcomed.

Official curriculum reference

Report a correction or ask a question