Program Testing and Maintenance

Every fault in a program falls into one of three types. Knowing which one you are looking at tells you when it shows up and how to find it.

Syntax error — the code breaks the rules (grammar) of the programming language (a missing bracket, a misspelt keyword, a missing quote). The translator (compiler or interpreter) reports it and the program will not translate at all.

Logic error — the code follows every language rule, so it translates and runs, but it gives the wrong or unexpected result. There is nothing to flag it automatically; you find it by testing and dry running and comparing the output with what you expected.

Run-time error — the program fails while it is executing: it crashes or hangs. Common causes are dividing by zero, accessing an array index that does not exist, or an infinite loop.

Locating and correcting errors is a regular Paper 2 task: you are given a code snippet, asked to name the error type, state the faulty line and write the corrected line.

You deal with faults in two ways: avoid them as you write, and expose the ones that slip through.

Avoiding faults (good practice while developing):

• Modular design — break the problem into small, separately testable modules.
• Meaningful identifiers and comments — make logic easier to read and check.
• Walkthroughs / desk checks — review code by hand before running it.
• Validating inputs so bad data cannot cause run-time errors.

Exposing faults (finding what remains):

• Dry running with trace tables to check the logic.
• Systematic testing with carefully chosen test data (next section).
• Testing each module, then the modules together (integration testing).

The aim is to find faults as early as possible — a fault caught during a walkthrough is far cheaper to fix than one found by a customer after release (which becomes corrective maintenance).

Good testing needs the right data, not just lots of data. There are three categories you must be able to choose (and the exam often asks for all of them):

• Normal data — valid and typical values that the program should accept and process correctly.
• Abnormal (erroneous) data — invalid values that the program should reject (with an error message).
• Extreme / boundary data — testing right at the limits of the allowed range. Extreme = the largest/smallest valid value. Boundary = the values either side of a limit (one should be accepted, the one just outside should be rejected).

Example — a program accepts whole-number marks from 0 to 100:

Boundary testing catches the classic "off-by-one" fault, where a programmer writes > 100 instead of >= 100, so 100 is wrongly rejected.

You must be able to describe each method and choose the right one for a situation.

By hand (before/while coding):

• Dry run / walkthrough — work through the code by hand, usually with a trace table, recording each variable after every step. Used to check the logic and find logic errors.

Designing test data:

• White-box (structural) testing — based on the internal logic of the code. The tester designs data to make every path, branch and loop run at least once.
• Black-box (functional) testing — based only on inputs and expected outputs, ignoring how the code works inside. The actual output is compared with the expected output.

Putting modules together:

• Integration testing — combine modules that have already been tested individually and test that they work together / interface correctly.
• Stub — a placeholder for a module not yet written; it returns a fixed/dummy value so the calling module can be tested before all its dependencies exist.

Before release (who tests it):

• Alpha testing — done in-house by the developers' own staff.
• Beta testing — done by a selected group of external users in real conditions, who report problems back.
• Acceptance testing — done with/for the customer, who confirms the software meets the agreed requirements before accepting it.

Testing must be organised, or parts of the system get missed and there is no evidence the software works.

A test strategy sets out the overall approach: which testing methods will be used, at which stages (e.g. module testing → integration → acceptance), and who is responsible. It is the plan-of-attack for the whole project.

A test plan turns that into a detailed, systematic schedule of individual tests, so testing is repeatable and complete. A typical test plan is a table, and for each test it records:

Test no.	Part/module	Test data	Category	Expected result	Actual result
1	Mark entry	57	Normal	Accepted	Accepted ✓
2	Mark entry	150	Abnormal	Rejected	Rejected ✓
3	Mark entry	100 / 101	Boundary	Accept / Reject	…

The expected result column is what makes testing meaningful: you compare the actual result against it. If they differ, you have found a fault to fix and re-test.

Software is not 'finished' at release — it needs continuing maintenance because faults are found, environments change and users want improvements. There are three types:

• Perfective maintenance — improving or enhancing a program that already works: adding new features, improving the interface, making it faster. Example: adding a new search feature users requested.
• Adaptive maintenance — changing the program so it keeps working in a new or changed environment / to meet changed external requirements. The program is not broken — its surroundings changed. Example: updating it to run on a new operating system, or to use a new tax rate set by law.
• Corrective maintenance — fixing faults (bugs/errors) discovered after release. Example: repairing a logic error that miscalculates a discount.

Amending an existing program to enhance functionality (a Paper 2 task) is perfective maintenance: you analyse the given code, add the new feature, then re-test the whole program because new code can introduce new faults elsewhere.