12.3 Program Testing and Maintenance

Bulk view disabled for Guests. View lessons individually.

Testing and Debugging

1. The Two Main Approaches

In the 9618 syllabus, you must distinguish between testing the logic and testing the functionality.

Black-Box Testing

The tester does not see the code. They provide Inputs and check if the Outputs match the requirements.

Focus: Does the software do what it's supposed to do?

White-Box Testing

The tester has full access to the source code. They ensure that every possible path (every IF, loop, and branch) is executed at least once.

Focus: Is the internal logic efficient and error-free?

2. Scenario-Based Testing Types

Scenario A: You've just finished the login module for your voting system. You need to ensure it blocks unauthorized users.
➔ Alpha Testing: Done by your own team. You try to "break" the login by entering weird characters or massive strings to check for SQL injection vulnerabilities.
Scenario B: The voting system is feature-complete, but you want to see how real voters interact with the interface before the actual election.
➔ Beta Testing: You release the software to a small group of trusted external users who use it in their own environments and report bugs or UX issues.
Scenario C: You've updated the database connection script to use a faster PHP library. You need to make sure the voting tallying logic still works.
➔ Regression Testing: Re-running previous tests to ensure that new changes haven't introduced bugs into parts of the code that were already working.
Scenario D: The system is being handed over to the electoral commission. They need to verify it meets all legal and technical specifications.
➔ Acceptance Testing: The final test performed by the end-user (customer) to prove the system is ready for "Live" use.

3. Choosing Test Data

When designing a Test Plan, you must include four types of data to prove your algorithm's robustness. Consider an input field for a "Student Grade" (0 to 100):

Type Description Example
Normal Data that is well within the acceptable range. 50, 82, 14
Boundary Data at the extreme ends of the acceptable range. 0, 100
Abnormal Data of the wrong type or outside the range. -5, 150, "Ten"
Extreme Data that is at the very limit of what the system can handle. 99.9, 0.1
⚠️ Exam Note: Dry Runs (Trace Tables)

A Dry Run is a manual form of testing. In Paper 2, you are often given an algorithm and a set of test data and asked to fill out a trace table. This is a "human" version of White-Box Testing because you are following every logical branch in the code.