**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.

| 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:** **S**yntax · **L**ogic · **R**un-time · **V**alidation

| 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.

- **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](/sd/C08/Types%20of%20Test%20Data).

- **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.

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`.