Input validation and error-message table
Every input, its rule, test values and the exact message.
What it explains and when it is useful
A validation table lists every input the user can give, the rule it must pass, valid and invalid examples, and the exact message shown when it fails.
When to use it: Any solution that accepts input: forms, command-line arguments, files, API requests. It feeds straight into the abnormal tests in your test plan.
Worked example
Illustrative: PracticePal is a fictional project used throughout this guide.
| Input | Validation rule | Valid example | Invalid examples | Message shown |
|---|---|---|---|---|
| Email (login) | Present; format x@school.org | m.l@school.org | (blank), m.l@gmail.com | “Use your school email address.” |
| Password (login) | Matches stored hash | – | wrong password | “Email or password incorrect.” (never says which) |
| Room | One of P1–P6 | P5 | P9, p5x, (blank) | “Choose a room from the tabs.” |
| Slot start | Mon–Fri, 07:30–17:00, :00 or :30, not past, ≤ next week | 2026-11-03 12:30 | 03:00, Sat, 12:15, last week | “That time can't be booked.” |
| Loud | Only if the room allows loud instruments | P5 + loud | P1 + loud | “P1 is a quiet room.” |
| Block dates (admin) | from ≤ to; both dates; ≤ 1 term | 9–13 Nov | 13 Nov to 9 Nov | “End date is before start date.” |
| Report week (admin) | A past or current ISO week | 2026-W45 | 2030-W01 | “No data for that week yet.” |
Rules that depend on other data (clashes, the weekly cap, noise) are not input validation; they are processing rules, shown in the flowchart and decision table.
Notation and legend
| Symbol or part | Meaning |
|---|---|
| Validation rule | Type, presence, range, format, length or lookup check |
| Invalid examples | Become abnormal and extreme test data in C3 |
| Message | The exact words: clear, polite, says how to fix it |
Design decisions it communicates
A diagram earns marks when you explain the decisions it shows. In PracticePal's documentation these would each be one sentence:
- Login errors never say whether the email exists (security).
- Times are restricted in the interface as well, but the server checks again because requests can be faked.
- Messages tell the user what to do next.
Common mistakes
- Only valid examples.
- Messages like “Error 400” or “Invalid input”.
- Checking only in the browser.
- Mixing validation with business rules.
Checklist for your own version
Ticks are saved in this browser only, so you can use the list while you draft.