In simple terms
A friendly intro before the formal notes — no formulas yet.
Testing: Finding the Faults
Program testing is the systematic process of finding errors in software before it reaches the user. Effective testing involves using a variety of data to check that the program behaves as expected in all situations.
Think of testing a new video game. The developers don't just play the 'perfect' path. They try to walk through walls (abnormal data), jump right at the edge of a platform (boundary data), and complete levels in the intended way (normal data). They record every crash or glitch, fix it, and then re-test to make sure the fix didn't break something else.
- 1
Create a Test Plan: Decide what you need to test and what the correct outcome should be for each test.
- 2
Select Test Data: Choose a range of data, including normal, boundary, and abnormal values, to challenge your program.
- 3
Execute and Record: Run the tests and carefully document the actual results, comparing them to your expected outcomes.
- 4
Maintain and Improve: Fix any identified bugs (corrective maintenance) and re-run tests to ensure stability.
Explore the concept
Use the live diagram and synced steps — play it or tap a step card to walk through.
Full topic notes
Formal explanation with the rigour you need for the exam.
Testing Strategies: Black-Box vs. White-Box
Before you even write your first test, you need a strategy. The two main approaches are defined by how much you know about the program's inner workings. For your P2 exam, you will primarily be performing black-box testing, but you must know the difference.
Black-Box Testing: You test the program's functionality based solely on its specification. You provide inputs and check if the outputs are correct, without any knowledge of the internal code. This is what an end-user or a dedicated tester would do.
White-Box Testing: You test the program's internal logic and structure. You have access to the source code and design tests to ensure that every line of code and every possible path is executed. This is typically done by the developer.
Choosing Effective Test Data
The quality of your testing depends entirely on the quality of your test data. Simply testing with one valid input is not enough. A thorough test plan uses three categories of data to check for robustness.
Normal Data: Sensible, valid data that the program is expected to accept and process correctly. For a percentage score (0-100), normal data might be 25, 50, or 75.
Boundary Data: Data at the edges of the valid range. This is where errors often occur. For a percentage score, boundary data would be 0, 100 (the limits), and also -1 and 101 (just outside the limits).
Abnormal Data: Data that the program should reject. This includes data of the wrong type (e.g., text instead of a number) or values that are far outside any logical range. For a percentage score, this could be 'fifty' or 5000.
Program Maintenance
A programmer's job doesn't end when the software is delivered. Software evolves. It needs to be fixed, updated, and improved over time. This ongoing process is called maintenance, and it falls into four categories.
Corrective Maintenance: The most common type. This is fixing bugs discovered by users after the program is in use. For example, fixing a crash that occurs when a specific button is pressed.
Adaptive Maintenance: Modifying the program to keep it functional in a changing environment. This could mean updating it to run on a new version of an operating system or to interact with a new database system.
Perfective Maintenance: Adding new features or improving existing ones to enhance the user's experience. This is often driven by user requests. For example, adding a 'dark mode' to an application or making a search function faster.
Preventive Maintenance: Changing the underlying code to improve its structure and readability, making future maintenance easier. This is like 'tidying up' the code (refactoring) to prevent future bugs and simplify future updates. It doesn't add new features for the user.
Worked examples
See the formulas applied — reveal one step at a time, like the exam.
A program includes a function CheckDiscount(Age) that returns TRUE if a person is eligible for a discount and FALSE otherwise. The discount is available for ages 18 to 25 inclusive. Complete a test plan with four distinct test cases for this function.
- 1
Here is a sample test plan. Note the justification for each data choice.
A procedure CalculateGrade(Score) is designed to work with integer scores from 0 to 100. Create a test plan with five test cases to check its robustness.
- 1
The goal is to test the input validation and handling of edge cases.
How it all connects
The big idea sits in the middle — tap a linked idea to explore the link.
Tap a linked idea to see how it connects back to the main topic — that connection is what examiners reward.
Glossary
Try to recall each definition before you reveal it.
Quick check
Answer in your head first — then tap to check. No pressure.
Revision flashcards
Flip the card. Test yourself before the exam.
What is Black-box testing?
Testing the functionality of a program without seeing the internal code structure. It is based on the requirements and specifications. Also known as functional testing.
Key takeaways
Review these before you close the topic — retrieval beats re-reading.
- ✓
Black-Box Testing: You test the program's functionality based solely on its specification. You provide inputs and check if the outputs are correct, without any knowledge of the internal code. This is what an end-user or a dedicated tester would do.
- ✓
White-Box Testing: You test the program's internal logic and structure. You have access to the source code and design tests to ensure that every line of code and every possible path is executed. This is typically done by the developer.
Practice — then mark it
The whole point: a real Cambridge question, marked mark-by-mark.
Practice Test Data Selection
Practice Test Data Selection
Extra simulations & links
PhET, GeoGebra and other curated tools — open in a new tab.
Frequently asked
Checkpoint
One marked question is worth ten re-reads — close the loop before you move on.
Reading it isn’t knowing it — prove it.
Before you move on: do Practice Test Data Selection on paper, snap a photo, and get examiner-style feedback on exactly where you win and lose marks.