3.3.2 - Formative project skills: testing and remedial action

Record a test another person can repeat

A developmental test checks a feature while the solution is being built, so its result can inform the next iteration. Testing belongs alongside each implemented stage: test the input validator when it exists, then the calculation, then the connection between them. Waiting until the whole product is finished loses the evidence of how failures influenced development.

Start from a requirement and predict the expected result independently of the program. In a miniature label-printing tool, requirement R2 allows an integer number of copies from 1 to 40 inclusive. The reason for testing 1 is to check that the lowest permitted order is accepted. “It is boundary data” identifies the category; the link to R2 explains why this boundary matters.

Record the version or iteration, test identifier, initial state, exact inputs/actions, expected result, actual result and outcome. Keep an evidence reference to an actual capture of the execution, and annotate what it demonstrates. A test table organises the record; a filled-in Pass cell alone does not show that the test was performed.

This is a supplied practice record, not evidence that you executed a learner project. In your own external IDE or GUI practice, capture the real result and identify its version. A screenshot should show the relevant input and output; if a state change is not visible in one image, use clearly linked before/after evidence. Preserve genuine failures rather than replacing their records with later successes.

Find the cause before changing the code

Debugging investigates why the observed behaviour differs from the requirement; testing reveals the difference. Reproduce a failure in the recorded version before changing it. Then reduce the failing journey to the smallest relevant operation, inspect the values at that operation, and compare the condition or state change with the requirement.

Here is the static validator from the label example. Its contract is a prevalidated integer parameter; parsing the text field is a separate operation.

def permitted(copies):
    return 1 < copies <= 40

For copies = 1, the first comparison is false. The program therefore returns False, although R2 requires acceptance. A normal value such as 20 returns True; this explains why testing only ordinary orders would miss the fault. The error is in the lower-bound comparison, rather than evidence that the entire input system must be rewritten.

In an external IDE, a breakpoint before the return and a watch on copies can distinguish two hypotheses: the parser supplied the wrong value, or the condition rejected the correct value. Step to observe which condition is taken. Diagnostic evidence showing copies = 1 and a false condition supports the second hypothesis. If the value were 0 instead, investigate the earlier conversion or assignment. Do not describe either hypothesis as established before checking it.

A crash on entering many is another kind of failure. It belongs to the text-to-integer conversion and error handling, not to this helper's integer-only contract. Record the error message and the action that produced it. Rejecting malformed text with an informative message may be the intended behaviour; an uncontrolled crash is not the same thing as controlled rejection.