Unit 4: Digital Development Concepts – Developing Test Plans and Testing a Solution
Welcome to your study notes on Developing Test Plans and Testing a Solution! Testing is one of the most important steps when developing computer software. Think of it like safety-testing a roller coaster before the theme park opens: you want to make sure everything works smoothly, handles unexpected events safely, and keeps users happy. Don't worry if this topic seems detailed at first; we will break down every key concept step-by-step so you feel fully confident for your CCEA exam.
---1. What is Testing and Why Do We Test?
Testing is the systematic execution of a program or system under specified conditions to find errors, bugs, or defects, verify that it meets user requirements, and make sure it is robust and stable.
There are three primary reasons why developers test software:
1. Meeting User and Functional Requirements: Software must do exactly what the client or end-user asked for in the original specification.
2. Verifying Correct Outputs: We must prove that code produces the expected, accurate results for given inputs.
3. Ensuring Robustness and Error Resilience: Software should be reliable and maintain data integrity, meaning it will not crash when given unexpected or invalid inputs.
Did You Know? Testing cannot prove that a program is \(100\%\) free of bugs—it is designed to uncover as many errors as possible so they can be fixed before release!
Important Distinction: Testing vs. Debugging
Students often mix these two terms up in exam questions. Make sure you remember the difference:
• Testing: The process of detecting and identifying the presence of bugs, errors, or unexpected behaviour in a system.
• Debugging: The process of locating the root cause of the fault within the code and correcting (fixing) it.
Key Takeaway: Testing finds the problem; debugging fixes the code.
---2. Levels and Stages of Testing
Software is rarely tested all at once at the very end. Instead, testing happens in logical stages as the program is built.
Analogy: Imagine building a car. First, you test the individual spark plugs (Unit Testing). Next, you connect the spark plugs to the engine block and test how they work together (Integration Testing). Then, you test the entire assembled car on a test track (System Testing). Finally, you let real drivers test-drive the car on normal roads (User Acceptance Testing).
The Four Key Testing Stages
1. Unit Testing (Modular Testing):
Testing individual subroutines, modules, or units of code completely in isolation. This ensures each small component works properly on its own before being joined with other code.
2. Integration Testing:
Combining individual software modules and testing them collectively. This checks that data flows correctly across interfaces and that components interact properly.
3. System Testing:
Testing the complete, fully integrated software application from start to finish to confirm that all functional requirements are satisfied.
4. User Acceptance Testing (UAT) / Beta Testing:
Testing the software with real end users under real-world operating conditions. This confirms that the software satisfies the actual business needs before final release or deployment.
Key Takeaway: Testing moves from small, individual parts (Unit) to combined parts (Integration), to the whole software (System), and finally to the end user (UAT).
---3. Categories of Test Data
To thoroughly test a program, you must feed it different types of test data. In the CCEA specification, test data is divided into four standard categories.
Let's use a clear example: Imagine an input box for a school club that only accepts ages from \(11\) to \(18\) inclusive (i.e. \(11 \le \text{age} \le 18\)).
1. Normal / Valid Data
• Definition: Data that falls comfortably within the expected, allowable range that the program is designed to accept and process without error.
• Example: Entering \(15\) into the age field.
• Expected Result: The data is accepted and processed successfully.
2. Boundary / Extreme Data
• Definition: Data values that sit exactly at the absolute outer limits or edges of acceptable ranges.
• Example: Entering \(11\) (the minimum valid limit) or \(18\) (the maximum valid limit).
• Expected Result: The data is accepted because it lies on the valid threshold.
3. Invalid / Erroneous Data
• Definition: Data that is of the correct data type (e.g. an integer), but falls outside the acceptable range.
• Example: Entering \(-1\) or \(25\) into the age field.
• Expected Result: The system rejects the input and displays an appropriate error message.
4. Illegal / Inappropriate Data (Type Error Data)
• Definition: Data of an incorrect data type altogether.
• Example: Entering text like "Fifteen" or symbols like "!@#" into a numeric age field.
• Expected Result: The system rejects the input, does not crash, and prompts the user to enter a valid number.
Common Examiner Trap to Avoid!
Boundary Data vs. Invalid Data: Many students mistakenly label numbers just outside the boundary (like \(10\) or \(19\)) as "boundary data". In CCEA exams, Boundary / Extreme Data refers to the valid limits themselves (\(11\) and \(18\)). Values outside the range (like \(10\) and \(19\)) are classified as Invalid Data.
Key Takeaway: Always test Normal, Boundary, Invalid, and Illegal data to prove a system is robust.
---4. Structure of a Test Plan
A Test Plan is a structured document prepared before testing begins. It outlines exactly what will be tested, what data will be used, and what result is expected.
Standard CCEA Test Plan Columns
When designing a test plan table for your exam or coursework, you must use the standard column headers:
• Test No. / Test ID: A unique reference number (e.g. Test 1, Test 2).
• Test Description / Purpose: What specific rule or feature is being tested (e.g. "Validate that student score cannot exceed 100").
• Test Data Used: The exact value entered (e.g. \(101\)).
• Type of Test Data: The classification (e.g. Normal, Extreme, Invalid, or Illegal).
• Expected Result: What the software should do (e.g. "Display error prompt: 'Score must be between 0 and 100'").
• Actual Result: What actually happened when the test was run (recorded during execution).
• Remedial Action / Retest Notes: What action is taken to fix the code if \(\text{Actual Result} \ne \text{Expected Result}\), followed by re-testing.
Worked Example of a Test Plan
Requirement: An exam score input system must only accept whole numbers between \(0\) and \(100\) inclusive.
Test ID: 1
Test Description: Test valid mid-range score
Test Data: \(65\)
Type of Data: Normal
Expected Result: Score accepted; confirmation message shown
Actual Result: Score accepted; confirmation message shown
Remedial Action: None required
Test ID: 2
Test Description: Test lower boundary score
Test Data: \(0\)
Type of Data: Boundary / Extreme
Expected Result: Score accepted; confirmation message shown
Actual Result: Score accepted; confirmation message shown
Remedial Action: None required
Test ID: 3
Test Description: Test upper boundary score
Test Data: \(100\)
Type of Data: Boundary / Extreme
Expected Result: Score accepted; confirmation message shown
Actual Result: Score accepted; confirmation message shown
Remedial Action: None required
Test ID: 4
Test Description: Test score exceeding maximum range
Test Data: \(101\)
Type of Data: Invalid / Erroneous
Expected Result: Error message: "Score out of range (0-100)" displayed; user prompted to re-enter
Actual Result: System crashed
Remedial Action: Corrected validation logic in subroutine; re-tested successfully
Test ID: 5
Test Description: Test non-numeric input
Test Data: "Pass"
Type of Data: Illegal / Inappropriate (Type Error)
Expected Result: Error message: "Please enter a valid number" displayed
Actual Result: Error message displayed
Remedial Action: None required
Examiner Tip: Writing Precise Expected Results
Never write vague phrases such as "it works", "it fails", or "it rejects the input". State the exact outcome: e.g., "Displays error message 'Score out of range' and prompts user to re-enter."
Key Takeaway: A complete test plan includes clear IDs, specific test data, correct data classifications, and detailed expected outcomes.
---5. Quick Review Checklist
Before moving on to the next chapter, check that you can:
• Define testing and state its three main purposes.
• Clearly explain the difference between testing (finding errors) and debugging (fixing code faults).
• List and explain the four stages of testing: Unit, Integration, System, and User Acceptance Testing (UAT).
• Identify and give examples of Normal, Boundary/Extreme, Invalid, and Illegal test data for any given range.
• List all standard column headers required in a CCEA Test Plan and write detailed, precise expected results.