Unit 5: Digital Development Practice — Testing a Solution
Welcome to this guide on Testing a Solution! In your GCSE Digital Technology coursework (Controlled Assessment for Unit 5), building your program is only half the job. You also need to prove that it works, does what it is supposed to do, and does not break when someone makes a mistake. Testing is the process that allows you to prove all of that clearly and methodically.
Don't worry if creating test plans seems tricky or repetitive at first. Once you understand the basic rules and data types, filling out a CCEA test plan is straightforward and gives you an easy way to secure high marks.
1. Why Do We Test? (Purpose and Role)
Imagine buying a new smartphone, typing in your password, and having the phone instantly shut down forever. You would not be happy! Programmers test their software extensively before handing it over to users.
The main purposes of testing are:
• Verify functional requirements: Making sure every feature works as intended (e.g. mathematical calculations work, files save and load properly, menus navigate to the correct screens).
• Check data validation: Making sure the program checks user input and rejects bad data without crashing.
• Ensure robustness: Confirming that the software handles unexpected or incorrect inputs gracefully and keeps running.
Did you know? In professional software development, programmers often write their tests before they even write the actual code. This ensures they always keep the end goal in mind!
Key Takeaway:
Testing proves your program works correctly, meets every requirement from the brief, and handles errors safely without crashing.
2. The Three Types of Test Data
To test a program thoroughly, you cannot just type in standard, correct answers every time. CCEA requires you to use and justify three specific types of test data:
A. Normal Test Data
• What it is: Data that falls comfortably within the valid range and expected format.
• Example: If an age input accepts numbers from \(1\) to \(100\), entering \(25\) is normal data.
• Expected Outcome: The data is accepted and processed correctly by the program.
B. Extreme (or Boundary) Test Data
• What it is: Data values that sit right on the upper and lower limits (edges) of what is accepted.
• Example: For an age range of \(1\) to \(100\), the extreme values are exactly \(1\) and \(100\).
• Expected Outcome: The data is accepted and processed correctly at the very boundary edges.
C. Erroneous (or Invalid) Test Data
• What it is: Data that is outside the acceptable range or of the wrong data type/format entirely.
• Example: For an age range of \(1\) to \(100\), entering \(-5\), \(150\), or typing the word "twenty" is erroneous data.
• Expected Outcome: The data is rejected. A clear, helpful error message appears on screen, and the program prompts the user to try again without terminating unexpectedly (crashing).
Memory Aid: The Doorway Analogy
• Normal: Walking straight through the middle of the open door.
• Extreme: Brushing past the very edges of the door frame while still getting through.
• Erroneous: Trying to walk straight into the solid brick wall next to the door!
Common Pitfall:
Do not confuse Extreme with Erroneous! Extreme data is valid and must be accepted (e.g. \(1\) and \(100\)). A value just outside the limit (e.g. \(0\) or \(101\)) is erroneous data.
Key Takeaway:
Always test all three: Normal (typical valid values), Extreme (valid boundary limits), and Erroneous (invalid or wrong type values that must be rejected).
3. The CCEA Test Plan Structure
For Unit 5, you must produce a detailed Test Plan table. Examiners look for a complete, structured table containing specific columns:
• 1. Test Number / ID: A sequential reference code (e.g. Test 1, Test 2).
• 2. Feature / Description of Test: What specific function, input field, or calculation is being tested.
• 3. Type of Test Data: State whether it is Normal, Extreme, or Erroneous.
• 4. Test Data / Input Value: The exact value entered into the system.
• 5. Expected Result / Outcome: The exact result the program should produce (e.g. a specific calculated value or an error message).
• 6. Actual Result / Outcome: What actually happened when you ran the code.
• 7. Action Taken / Remediation: If a bug occurred and the actual result did not match the expected result, describe the code changes made and note the re-test result.
• 8. Evidence / Screenshot Reference: A cross-reference to an annotated screenshot proving the test was executed in your coding environment.
Example Test Plan Row:
Test ID: Test 04
Feature: Exam Mark Input (Valid range: \(0\) to \(100\))
Type of Test Data: Erroneous
Test Data: \(105\)
Expected Result: Error message displayed: "Invalid mark. Please enter a value between 0 and 100." Input rejected.
Actual Result: Error message displayed; mark rejected.
Action Taken: None required (test passed).
Evidence Ref: Screenshot 4 (Appendix B)
Common Pitfalls to Avoid:
• Vague Expected Outcomes: Never write "it works" or "gives an error". Write the exact wording of the message or the exact calculated number (e.g. "Total cost displays £14.50").
• Hiding Failed Tests: If a test fails, do not change your expected outcome to match your broken code! Record what happened, explain the code fix in the Action Taken column, and re-test.
• Missing Screenshots: Every test in your plan should have a corresponding cropped, numbered, and annotated screenshot showing the actual code running with that input.
4. Levels and Types of Testing
Testing takes place at different stages as you build your solution. You should be familiar with these four key levels:
• Iterative / Unit Testing: Testing individual subroutines, functions, or calculation blocks as you write them. This helps you catch and fix bugs early before moving on to the next part of your code.
• Integration Testing: Testing how different modules, subroutines, and files work together (e.g. ensuring a function passes the correct calculated value to a file-saving routine).
• System / Final Functional Testing: Testing the entire completed program from start to finish against all original requirements from the assignment brief.
• User Interface / Usability Testing: Testing how easy the program is to use — checking screen layouts, navigation buttons, clear instructions, and readable font sizes.
Key Takeaway:
Test as you go (Unit testing), test how pieces fit together (Integration testing), test the final complete program (System testing), and test the user experience (Usability testing).
5. Types of Programming Errors
When running tests, you are hunting for errors (bugs). There are three main categories of programming errors you must understand:
A. Syntax Errors
• Definition: Mistakes in the grammar or rules of the programming language.
• Examples: Misspelling a keyword (e.g. typing prnt instead of print), missing colons, or unclosed brackets.
• When detected: Caught by the compiler or interpreter before the program can run.
B. Runtime Errors
• Definition: Errors that occur while the program is running, causing it to crash or stop suddenly.
• Examples: Attempting to divide a number by zero (\(x / 0\)), searching for a file that does not exist, or accessing an index outside the boundaries of a list.
• When detected: Only when the specific line of code is executed during runtime.
C. Logic Errors
• Definition: The program runs without crashing, but it produces the wrong output or behaves incorrectly due to a mistake in the algorithm.
• Examples: Using \(>\) instead of \(\ge\), adding two numbers together when they should be subtracted, or using the wrong formula to calculate an average.
• When detected: By systematically comparing your test's Expected Result against the Actual Result.
Quick Error Summary:
• Syntax: Broken language rules → program won't start.
• Runtime: Illegal operation while running → program crashes.
• Logic: Flawed calculation or decision → program runs, but gives the wrong answer.
Quick Review Checklist
Before submitting your Unit 5 Controlled Assessment test section, verify that you have:
• Included all 8 required columns in your test plan table.
• Tested Normal, Extreme, and Erroneous data for every input field.
• Written detailed, specific Expected Outcomes (not just "it works").
• Documented fixes in the Action Taken column for any tests that failed initially.
• Provided numbered, clear screenshot evidence for each test.