← Course home National 3/4 Computing Science  ·  James Gillespie's
N3/N4  ·  SDD  ·  Software Design & Development

Testing, Common Errors and Fixing Them

National 3 & National 4 Computing Science Lesson SDD7 of 10 Approx 55 min
Learning intentions
  • Use test data to check whether a program works correctly
  • Recognise syntax, runtime and logic errors in Python programs
  • Fix errors by reading messages, tracing values and testing again
Success criteria
  • I can choose normal, extreme and exceptional test data
  • I can explain the difference between syntax, runtime and logic errors
  • I can record a test, expected result, actual result and fix
Warm up — what do you already know?

These questions check the ideas you need before testing a program.

1. Which type of error stops Python understanding the code before it runs?

2. A program runs but gives the wrong answer. What kind of error is most likely?

3. Why should expected results be written down before running a test?

Key vocabulary

Test data
Input values chosen to check whether a program works.
Expected result
What should happen if the program is correct.
Actual result
What really happens when the program is run.
Syntax error
An error caused by code that breaks Python's grammar rules.
Runtime error
An error that appears while the program is running.
Logic error
An error where the program runs, but gives the wrong result.

Testing, Common Errors and Fixing Them

Testing is planned checking

Testing is not just running a program once and hoping it works. A useful test has four parts: the test data, the expected result, the actual result, and a decision about whether the program passed. The expected result should be written before the program is run. That stops you from changing the answer to match a broken program.

Choosing test data

Good test data covers the different kinds of input the program should handle. Normal data is ordinary data that should be accepted. Extreme data is right on the edge of a condition, such as 12 and 13 when the rule changes at age 13. Exceptional data is data the program may not be able to use, such as text where a number is expected.

Three common error types

A syntax error means Python cannot understand the code, often because a colon, bracket or indentation is missing. A runtime error happens while the program is running, for example when trying to convert the word "ten" into an integer. A logic error is when the program runs but the algorithm is wrong, such as using > when the rule needs >=.

Fix, then test again

Fixing code is a cycle. Read the message or output carefully, identify the likely line, make one sensible change, then run the same test again. If you make lots of changes at once, you may not know which change fixed the problem. A clear test table is evidence that you can test and refine a solution.

Worked examples

Example 1 — boundary testing

A cinema program charges a child price if age is under 13.

1
Normal test: age 10 should give child price.
2
Extreme tests: age 12 should give child price, age 13 should give adult price.
3
If age 13 still gives child price, the condition is probably wrong.
Example 2 — spotting a syntax error
if score >= 5 print("Pass")
1
The condition line needs a colon at the end.
2
Correct version: if score >= 5:.
Example 3 — logic error

A discount should apply when total is 20 or more, but the code says if total > 20:.

1
Test with 20. Expected: discount applies.
2
Actual: discount does not apply.
3
Fix: change the condition to if total >= 20:.
Now you try

A program should print "Pass" for marks of 50 or above. It uses if mark > 50:. Choose three tests and explain the bug.

Use 49, 50 and 51. 49 should fail, 50 should pass, 51 should pass. The condition should be mark >= 50 because 50 is included in the pass range.

Common mistakes
✕
Only testing one easy value. One normal test does not prove the boundary works.
✕
Writing expected results after running the program. Expected results must come first.
✕
Assuming no error message means no error. Logic errors often have no message.
Tip

For assessment evidence, your test table should show the test data, expected result, actual result and whether a fix was needed. This maps directly to N3 O1.3 and N4 O2.3.

Task Set

Use these questions to practise identifying errors and recording tests.

1. Which error type is caused by missing a colon after if score >= 5? TYPE 1

2. A program divides by zero while running. What kind of error is this? TYPE 1

3. For a rule that changes at age 13, which pair is best for extreme testing? TYPE 1

4. Explain why if mark > 50: is wrong if 50 is meant to be a pass. TYPE 2 N3

The condition leaves out 50. If 50 should pass, the condition needs to be mark >= 50.

5. Make a test table for a program that charges 2.00 if age is under 13 and 5.00 otherwise. Include three tests. TYPE 2 N4

Example tests: age 10, expected 2.00; age 12, expected 2.00; age 13, expected 5.00; age 14, expected 5.00. Include actual results after running.

6. Practical: Create sdd7_testing.py. Write a small program with one selection rule, test it using normal and extreme data, then record any fix you made. TYPE 3

A strong answer includes the code, at least three tests, expected and actual results, and a note of any bug fixed. For example, a pass/fail program should test 49, 50 and 51.
Teacher notes — Shift+T to hide

Suggested timing: 55 minutes. Emphasise boundary testing and expected-vs-actual language.

Assessment standards covered: N3 O1.3; N4 O2.3.