Testing Tables and Corrections
The testing table is the artefact the whole C8-1 rubric reads from: one row per test, and for every failed test, what you did about it.
Definition. A testing table documents each test case: the exact input you ran, the output you expected, the output you actually got, and — when the two disagree — the corrective action you took. Expected-vs-actual across a range of data is the 7–8 discriminator; a complete list of corrective actions for every failed test is the 9–10 one.
The structure
| Column | What goes in it |
|---|---|
| Test Case ID | TC001, TC002, … |
| Test Description | what this row proves, in one phrase |
| Input Data | the exact value(s) entered |
| Expected Output | the specific output — never just "works" |
| Actual Output | what really happened, even when it matches |
| Pass/Fail | one word |
| Error Type | S / L / R / V (below) |
| Corrective Action / Notes | for every Fail: what you changed, and the re-run result |
Error types: Syntax · Logic · Run-time · Validation
A worked slice
| Test ID | Description | Input | Expected | Actual | Result | Corrective action |
|---|---|---|---|---|---|---|
| TC001 | Valid login | saleh / OoeiO9! | Access granted, menu screen | Access granted, menu screen | Pass | — |
| TC002 | Wrong password | saleh / saleh | Error message | Access granted! | Fail | Login branch never compared the password — added the check; re-run: error shows ✅ |
| TC004 | Update existing profile | (edit form) | Profile updated, back to menu | Profile did not update | Fail | Save wrote to a copy, not the record — fixed reference; re-run: Pass ✅ |
The Fail rows are where the marks live: fault → fix → re-run result, written next to the row. That same fix cycle, performed live, is what your screen recording must show.
Rules that keep the table honest
- Write Expected before you run. An expected output copied from the actual output tests nothing.
- Never delete a failed row. The fail plus its corrective action is the evidence — a table of green Passes scores lower than one showing real fixes.
- Cover the range: valid, boundary, invalid, wrong, absent — see Types of Test Data.
- At least one row per validation rule in your code: the empty field, the out-of-range value, the wrong type — with the input that should trigger it.
Going further — automated tests
A unit test is a testing-table row written as code, so it re-runs itself after every change (in Godot: the GUT addon). A passing automated suite is strong "all modules function correctly" evidence for 9–10 — but the documented table stays the required artefact.
The blank template is in your class repo: S-C08/C081-Alpha-Testing-Plan-Template.md.