Testing Algorithms with Different Data Sets
Move beyond the "Happy Path"! Learn to crash-proof your code using Normal, Boundary, and Erroneous data.
Why Test with Different Data?
Beyond the "Happy Path": A program must do more than just work when everything is right; it must fail gracefully when things go wrong.
The Goal: To find "edge cases" where the logic might break down (e.g., dividing by zero).
Try this calculator! It expects a Number. What happens if you type a Letter?
Type 1: Normal Data
Definition: Data that falls squarely within the expected range and format.
Purpose: To verify that the basic logic and formulas are working as intended.
Example: If testing a "Pass/Fail" program for grades 0–100, normal data would be 65 or 42.
Input a normal value (0-100) to see the Trace Table logic flow.
IF Mark >= 50 THEN "Pass" ELSE "Fail"
Type 2: Boundary (Extreme) Data
Definition: Data at the very limits of the acceptable range.
The "Off-by-One" Trap: Many logic errors happen at the edges (e.g., using > instead of >=).
Example: For a grade range of 0–100, the boundary data points are exactly 0 and 100.
Logic: IF Age >= 18 THEN "Allow Entry". Use the slider to find the boundary!
Type 3: Erroneous (Invalid) Data
- Out of Range: Entering 105 for a percentage.
- Wrong Type: Entering "Ten" for an integer field.
Garbage In, Garbage Out? Not on your watch! Choose the best error message for the bad data provided.
Input: ??
Designing a Test Plan (Objective 7)
The Test Suite: Combining all three types of data into a single table to ensure 100% coverage.
Expected vs. Actual: The core of a test plan—predicting the result before running the trace.
| Test Case | Data Type | Input Value | Expected Result | Actual Result |
|---|---|---|---|---|
| 1 | Normal | 50 | "Pass" | "Pass" |
| 2 | Boundary | 0 | "Fail" | "Fail" |
| 3 | Erroneous | -5 | "Error" | "Pass" (Logic Error!) |
CSEC SBA Prep: The Testing Evidence
Documentation: How to present your test results in your SBA to prove you thoroughly checked your algorithm.
Annotating Errors: If a test fails (like row 3 above), explain why and how you fixed the pseudocode in your documentation.
Take screenshots of your algorithm displaying the outputs. Paste these into a Word document and type the "Expected Result" next to them.
Knowledge Check: The Quality Controller
The Scenario: "You are testing a program that accepts a month number (1–12)."