DoAssignment study guide

B1.3 · Code, test, deploy and document a product

Learn to code, test, deploy and document a product through clear examples and targeted practice.

Ontario Grade 12 Computer Science

Software Development

Coding, testing, deploying, and documenting in ICS4U

In ICS3U, you practised writing and tracing programs. In this lesson, you connect those skills to the work of making a product ready for its intended use. B1.3 focuses on coding, testing, deploying, and documenting a product. A program is not ready simply because its instructions have been written: its behaviour must be checked against what it is supposed to do, it must be prepared for its intended setting, and users need accurate information. The examples give reasoned traces and expected outputs; they do not claim that the displayed code was run.

What you will learn

Explain how coding, testing, deployment, and documentation contribute to a programming product.
Use a requirement and precondition to plan and trace a small program.
Choose tests that check ordinary and boundary inputs, and distinguish expected results from observed results.
Describe how to prepare a product for its intended users and keep its documentation accurate.

1. Review the plan: requirements, input, and preconditions

A requirement describes behaviour a product is expected to provide. Make it clear enough that someone can check whether the product meets it. For example: “Given a whole number of minutes from 0 to 59, display the equivalent number of seconds.” This names an input range and an expected kind of output.

A precondition is what must be true before the program is used as intended. For this example, the input must be a whole number in the stated range. Naming the precondition helps you decide what inputs to test. It also prompts a useful question: if the product might receive an input outside that range, what should it do?

Before coding, identify the user and purpose, state the input and expected output, and outline the steps in plain language. If the project brief does not settle an important detail, clarify it rather than silently choosing an interpretation. A short plan makes it easier to compare the finished program with the requirement.

A requirement states intended behaviour that can be checked.
A precondition states what must be true for the program to be used as intended.
State the input and expected output before tracing or testing.

2. Code and reason through a trace

Coding turns a plan into instructions in a programming language. Clear names and a direct structure help you and other readers compare the code with the requirement. Add comments when they clarify purpose or a decision; comments should not simply restate every instruction.

A trace follows the instructions for a particular input and works out the expected behaviour. It is a prediction derived from reading the code, not an observed test result. Tracing can reveal a mismatch with the requirement and helps you decide what to check during testing.

When you describe an example, identify its precondition and input, explain the steps, and state the expected output. If the code has not been run, do not call that output a test result.

The code should implement the stated requirement.
A trace derives expected behaviour for a chosen input.
A predicted output and an observed test result are different kinds of information.

3. Test, deploy, and document the product

Testing checks a product against its requirements. Choose inputs that matter to the stated behaviour: an ordinary valid input and values at the limits are often useful. For each test, write down the input and expected behaviour. When testing in the appropriate environment, record what is actually observed; do not replace observations with predictions. If inputs outside the preconditions are possible, decide how the product should respond and include that behaviour in its requirements.

Deployment means preparing and making the product available in its intended setting. That might be an approved classroom computer or another setting specified for the project. Check that the intended version and needed instructions are included and follow the rules of that setting. Deployment makes the product available; it does not by itself show that requirements have been met.

Documentation helps users or maintainers understand the product. User instructions can explain its purpose, accepted input, expected output, and relevant limitations. Notes for development can record requirements and tests performed. Keep documentation consistent with the product, and revise it when the product changes.

Plan tests from requirements and record actual observations accurately.
Prepare the correct version for the intended, approved setting.
Documentation should match the product and help its audience.

4. Review and revise as needed

These activities are connected. Testing may show that the code does not meet a requirement, so you revise the code and test the changed version. A change to the product may also make its instructions inaccurate. Before deployment, review the product, test records, and documentation together.

For a small classroom product, ask whether the code implements each requirement, whether the selected tests check relevant ordinary and boundary inputs, whether the product is prepared for its intended setting, and whether a user can follow the instructions. This review keeps attention on the work named in B1.3.

A test may lead to code changes and further testing.
Review code, test records, and documentation for the version being prepared.
Keep user instructions accurate when the product changes.

Worked example

Convert minutes to seconds

Requirement: for a whole-number input from 0 to 59, display the equivalent number of seconds. The precondition is that the input is an integer in that range. Trace the code for 7 and identify useful tests.

Python 3

minutes = 7
seconds = minutes * 60
print(seconds)

Identify input and steps
The input is a number of minutes satisfying the precondition. Multiply it by 60, then display the result as seconds.
Trace the input
For 7 minutes, multiplying by 60 gives an expected output of 420 seconds. This is a reasoned trace, not a claim that the code was run.
Choose tests
The inputs 0 and 59 check the endpoints, while 7 checks an ordinary case. Work out expected results first; record observations only when the program is actually tested in the intended environment.

Answer: For an input of 7, the expected output is 420 seconds. Tests at 0 and 59 check the precondition's endpoints. The product's instructions should state the accepted range.

Check: The input 59 meets the precondition; 60 does not. Specify how the product should respond to an out-of-range input if it may receive one.

Worked example

Check a score against its requirement

Requirement: accept an integer quiz score from 0 to 10 and display “Valid score” for an in-range score; otherwise display “Check score”. The input is assumed to have already been entered as an integer. Trace the code for 8 and 12.

Python 3

score = 8
if 0 <= score <= 10:
    print("Valid score")
else:
    print("Check score")

Read the condition
The accepted range includes both 0 and 10. The condition checks that the score is at least 0 and at most 10; both checks must be true to select the valid message.
Trace 8
The value 8 is between 0 and 10 inclusive, so the expected output is “Valid score”.
Trace 12 and plan tests
The value 12 is greater than 10, so the expected output is “Check score”. Testing 0 and 10 checks the endpoints. Testing a value below and above the range checks the stated alternative behaviour. These outputs are predictions from the code, not reported test observations.

Answer: The expected output is “Valid score” for 8 and “Check score” for 12. This version assumes integer input; it does not specify how text that is not an integer is handled.

Check: Documentation should state the accepted range and explain the messages. Do not claim the product handles input types that have not been specified.

Worked example

Prepare a product for its users

A classroom program uses a user's chosen whole number of items and a fixed price per item from the project brief to display a total. The brief supplies the allowed input range and price. Describe a completion plan without inventing values or claiming tests have been performed.

Illustrative product workflow

Stages are illustrative, not a measured schedule. The lower feedback link returns from testing to coding when revision is needed.

Pseudocode

INPUT item_count
IF item_count is within the brief's allowed range
    total = item_count * price_from_brief
    DISPLAY total
ELSE
    DISPLAY the brief's out-of-range response

Code from the brief
Use the brief's input range and price as the basis for the program. The algorithm accepts an item count, checks whether it is in range, calculates the total using the specified price, and displays the result. The brief must also define the response to an out-of-range value.
Plan and record tests
Choose an ordinary allowed count and the minimum and maximum allowed counts. Calculate expected totals from the brief, then compare them with observations when the product is tested. Since no values are provided here, no numerical result or test outcome can be stated.
Deploy and document
Prepare the agreed version for the approved classroom setting. Explain the accepted input and what total the program displays. If testing leads to a code change, review the changed behaviour and update the instructions before sharing the product.

Answer: The plan connects the project brief to code, planned tests, deployment, and user instructions. No numerical output or test result can be given without the price and input range from the brief.

Check: Before deployment, confirm that the code, test records, and instructions refer to the same requirements and version.

Common mistakes and how to avoid them

Calling a reasoned trace a test result.

Correction: Describe a trace as an expected result. Record an observed result only after testing.

Checking only one ordinary input.

Correction: Choose tests that also check relevant boundaries and other behaviour required by the product.

Sharing a product without explaining its accepted input.

Correction: Document the purpose, accepted input, expected output, and relevant limitations.

Leaving instructions unchanged after program behaviour changes.

Correction: Review and update documentation so it describes the version being prepared.

Lesson summary

Start with a clear requirement, input, output, and precondition.
Code the planned behaviour and trace chosen inputs to derive expected results.
Test against requirements, recording observations separately from predictions.
Deploy the prepared product in its intended setting and keep its documentation accurate.

Check your understanding

Question 1

A program accepts integers from 1 to 20 inclusive. Which input checks the upper endpoint?

0
20
21
A sentence

Show answer and explanation

20 is the stated upper endpoint, so testing it checks whether the endpoint is included as required.

Question 2

A trace predicts an output, but the program has not been run. Which statement is accurate?

The output is a recorded test result.
The program is ready for deployment.
The output is an expected result derived from the code.
Documentation is no longer needed.

Show answer and explanation

The output is an expected result derived from the code.

A trace supports a reasoned prediction. A test result requires an observation made during testing.

Question 3

A code change alters the message users see. What should happen before the revised product is shared?

Keep the old instructions because the code changed.
Update the documentation and review the revised product against its requirements.
Describe the predicted behaviour as an observed test result.
Skip testing because an earlier version was tested.

Show answer and explanation

Update the documentation and review the revised product against its requirements.

The documentation should match the revised product, and the changed version should be reviewed and tested against its requirements.

Key terms

Product: A program prepared to meet a stated need and intended for use.
Requirement: A statement of behaviour the product is expected to provide.
Precondition: A condition that must be true for a program or operation to be used as intended.
Trace: A step-by-step account of expected program behaviour for a particular input.
Deploy: Prepare and make a product available in its intended setting.
Documentation: Information that helps users or maintainers understand and use a product.

Continue through ICS4U

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

About this lesson and its review

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