DoAssignment study guide

A4.2 · Build a formal software test plan

Learn to build a formal software test plan through clear examples and targeted practice.

Ontario Grade 12 Computer Science

Programming Concepts and Skills

ICS4U A4.2 study lesson

In ICS3U, you learned to design and create programs. A4.2 focuses on planning how to check that a program behaves as its requirements say it should. A test plan makes those checks organized and repeatable: another person should be able to follow a test case and know what result to look for. In this lesson, we will plan tests for a small, hypothetical score-classification program. The requirements and expected results below are examples for learning; they are not results from running a program.

What you will learn

Explain the purpose of a formal software test plan.
Turn a clear program requirement into test cases with inputs and expected results.
Choose ordinary, boundary, and invalid inputs that check different parts of a requirement.
Record actual results and status clearly when tests are carried out.

1. From a requirement to a test plan

A test plan is a written plan for checking specified parts of a program. It connects what the program is supposed to do with particular checks. A plan is useful because a program can appear to work for one familiar input while failing for other inputs. Writing expected results before testing also helps prevent guesswork when someone observes the program.

Start with the requirement, not with a list of random values. For this lesson, the hypothetical program accepts a whole-number score from 0 through 100. It displays “Pass” for scores of 50 or higher and “Not yet” for scores below 50. It rejects inputs that are not whole numbers or are outside the allowed range. These details define what the tests must check.

For each test case, record an identifier, the feature being checked, any precondition, the input, the expected output, and—when the test is carried out—the actual output and status. A precondition states what must be true before the test begins, such as starting the program with no score already entered. Expected output is based on the requirement; actual output is observed during testing. Keep them separate.

A plan may also state its scope: what features are included and what is not being checked. It can identify who will carry out the tests, what version is being tested, and how results or problems will be recorded. These details help people repeat the plan and understand its limits.

Requirements determine what to test.
Write expected results from the specification, before observing the program.
Keep expected output separate from actual output and test status.

2. Selecting useful test cases

A test case should check a particular rule. Ordinary examples check typical behaviour. Boundary cases check values at or close to a rule’s limit. Invalid cases check that disallowed inputs are handled as required. For the score program, a score below 50, the exact threshold of 50, and a score above 50 check the classification rule from different sides.

The allowed score range has its own limits. Testing 0 and 100 checks the stated endpoints; values such as -1 and 101 check just beyond them. A text input checks the rule that the input must be a whole number. Each selected input should have a predicted result that can be compared with what the program actually does.

A test plan does not claim that the software passed. Before carrying out a test, its actual result and status are unknown. During testing, record the observed output and mark the case as passed only when that output matches the expected result. If it does not, record the difference clearly so the problem can be investigated.

Choose inputs because they exercise a stated rule.
Include typical, boundary, and invalid inputs when those cases are part of the requirements.
Never fill in an actual result or pass status based only on an expectation.

3. Recording and reviewing the plan

Make each test case specific enough that another person can follow it without guessing. State the starting condition, exact input, and expected output. Avoid directions such as “try a low score”; name the actual value and the result required by the specification.

Review the plan against the full requirement. Ask whether every stated rule has at least one relevant test, whether expected results follow from the rule, and whether the cases can be carried out and observed. If a requirement is unclear—for example, whether decimal scores are allowed—do not silently invent a result. The specification must be clarified before a reliable expected result can be written.

During execution, preserve the planned input and expected result, then enter the observed result and status. If a case fails, describe what differed rather than changing the expected result to match the program. This keeps the plan useful as a record of the checks and their outcomes.

Use precise, repeatable instructions.
Check that test cases cover the stated requirements.
Record observations honestly; a plan is not proof that testing occurred.

Compact test-case record

ID	Feature	Precondition	Input	Expected result before test
T02	Threshold classification	Program ready for a new score	50	Pass
T06	Range validation	Program ready for a new score	-1	Reject input

Worked example

Example 1: Drafting the plan’s scope

Create the opening information for a test plan for the hypothetical score-classification program. Its requirements are: accept whole-number scores from 0 to 100 inclusive; display “Pass” for 50–100; display “Not yet” for 0–49; reject non-whole-number or out-of-range input.

Preparing and recording a test

Expected results are written from the requirement; actual results are recorded only after observation.

Name the target
Identify the program and the behaviour the plan will check. Naming the feature keeps the plan focused on the supplied requirements.
Set the scope
Include accepted range, classification, and rejection of invalid input. Do not claim to check features that the requirement does not describe.
State the recording rule
Leave actual result and status blank until the test is carried out. This distinguishes a prediction from an observation.

Answer: Plan title: Score classification checks. Scope: Check acceptance of whole-number scores from 0 to 100 inclusive, the pass threshold, and rejection of non-whole-number or out-of-range input. Preconditions: Start the program in a fresh state, ready to receive one score. For each case, record the exact input and expected result before testing; record actual result and status only after observing the program.

Check: The scope includes every rule in the supplied requirement and does not claim any test has already been run.

Worked example

Example 2: Selecting cases for the threshold

Choose cases that check the score threshold and the allowed range. Give the expected result for each, based only on the stated requirements.

Check either side of the threshold
Use 49, 50, and 51. The first is below the threshold, the second is the threshold itself, and the third is above it.
Check range endpoints
Use 0 and 100 because both endpoints are explicitly allowed. Their expected classifications follow from the same threshold rule.
Check invalid values
Use -1 and 101 to check values just outside the range, and use 72.5 to check a value that is not a whole number. The requirement says these inputs are rejected.

Answer: Example cases: T01, input 49, expected “Not yet”; T02, input 50, expected “Pass”; T03, input 51, expected “Pass”; T04, input 0, expected “Not yet”; T05, input 100, expected “Pass”; T06, input -1, expected rejection; T07, input 101, expected rejection; T08, input 72.5, expected rejection. Preconditions for each: the program is ready for a new score. Actual result and status remain unfilled until the case is carried out.

Check: The threshold cases distinguish below, at, and above 50; the other cases check valid endpoints and invalid input types or range.

Worked example

Example 3: Recording an observed result

Suppose a tester carries out case T02 using input 50. The observed display is “Not yet”. Show how the plan should record this result.

Keep the planned expectation
The requirement says scores of 50 or higher display “Pass”, so T02’s expected result remains “Pass”.
Enter the observation
Record the displayed text exactly as observed: “Not yet”. Do not rewrite the observation to match the expected result.
Mark the status
Because the observed output differs from the expected output, record T02 as failed and note the difference for follow-up.

Answer: T02 — Feature: threshold classification. Preconditions: program ready for a new score. Input: 50. Expected output: “Pass”. Actual output: “Not yet”. Status: Failed. Note: observed output differs from the requirement-based expectation.

Check: The failure is identified by comparing the observed output with the expected output; the expected result is not changed to hide the mismatch.

Common mistakes and how to avoid them

Writing “test a low score” without naming the input or expected output.

Correction: Specify an exact value, such as 49, and the result required by the stated rule.

Treating an expected result as an observed result.

Correction: Write the expectation from the requirement before testing; record actual output only after observing it.

Changing the expected result after the program gives a different output.

Correction: Preserve the requirement-based expectation and record the mismatch as a failed test.

Testing only a typical value and assuming the limits work.

Correction: Include values at the stated boundaries and invalid cases when those behaviours are specified.

Lesson summary

A formal test plan connects program requirements to repeatable test cases.
A useful case records an identifier, feature, precondition, input, and requirement-based expected result.
Typical, boundary, and invalid inputs check different stated behaviours.
After a test is carried out, record the actual result and compare it with the expectation.

Check your understanding

Question 1

For the stated score program, what is the expected result for input 50?

“Not yet”
“Pass”
Reject input
The result cannot be determined

Show answer and explanation

“Pass”

The requirement says scores of 50 or higher display “Pass”, and 50 is an allowed whole-number score.

Question 2

A test case expects “Pass” but displays “Not yet”. What should the plan record?

Change the expected result to “Not yet”
Record the actual output and mark the case failed
Leave out the actual output
Mark the case passed because an output appeared

Show answer and explanation

Record the actual output and mark the case failed

The expected result comes from the requirement. A different observed output is a mismatch and should be recorded as a failure.

Question 3

Which set best checks the threshold boundary?

49, 50, and 51
10, 20, and 30
0, 25, and 100 only
50, 75, and 100

Show answer and explanation

49, 50, and 51

These values check just below, exactly at, and just above the threshold of 50.

Key terms

Test plan: A written plan describing what program behaviours to check and how to record results.
Test case: A specific check with a stated precondition, input, and expected result.
Precondition: A condition that must be true before a test begins.
Expected result: The output or behaviour required by the specification for a test input.
Actual result: The output or behaviour observed when a test is carried out.
Boundary case: A test of a value at or close to a limit stated in a requirement.

Continue through ICS4U

View the complete ICS4U Ontario Grade 12 Computer Science curriculum and lessons

Tutor support for A4.2 · Build a formal software test plan

Working on A4.2 · Build a formal software test plan in ICS4U? Bring the question and your own attempt. In a live session, you can trace a small example and find the first step where the output differs from what you expected. Ask about the first step that does not make sense, then try a similar question yourself.

Explore coding tutoring · Request an eligible free 30-minute introduction. Your request is matched by subject and language; a tutor must accept before a time is confirmed.

برای مبحث A4.2 · ساخت برنامه رسمی آزمون نرم‌افزار در درس ICS4U، سؤال و تلاش خود را همراه بیاورید. در جلسه می‌توانید یک مثال کوچک را دنبال کنید و نخستین گامی را که خروجی با انتظار شما فرق دارد پیدا کنید. راهنمای معلم برنامه‌نویسی را ببینید یا جلسهٔ معارفهٔ رایگان ۳۰ دقیقه‌ای درخواست کنید. زمان جلسه پس از پذیرش معلم قطعی می‌شود.

About this lesson and its review

Published by DoAssignment. This reviewed lesson follows Ontario Grade 12 Computer Science (ICS4U), expectation A4.2. 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