Separate the rules
Record what each rule explicitly says. Put the ambiguous capacity row into an open-question list instead of filling it with an assumption.
Concrete output: Rules and unanswered questions.
FICTIONAL LEARNING EXERCISE
Design tests for a fictional reservation
Practise test design using eight desk-based rules. This is not a live application test; no system requests are made.
Inspect the sample file
8 sample rows · 4 columns
| rule_id | field | rule | boundary_note |
|---|---|---|---|
| Q01 | name | required | empty string |
| Q02 | attendees | whole number from 1 to 4 | 0 and 5 outside range |
| Q03 | date | one of the supplied sample dates | other date not allowed |
| Q04 | contains @ in this exercise | not a real email standard |
The table shows the first four rows. The file is fictional; some exercises intentionally include missing or conflicting values. Do not interpret them as real operational outcomes.
Download fictional sample CSV ↓Choose two scenarios
Write a normal case and a boundary case using prerequisite, input, action and expected result. Do not claim to have run them on a real system.
Concrete output: Two desk-based test scenarios.
Map coverage
Map each scenario to the rule it addresses. Label an uncovered row as not yet covered rather than presenting it as a successful test.
Concrete output: A rule-to-scenario coverage table.
Explain the finding
Do not confuse a design question with an observed defect. State the exercise’s limits and the information needed before actual testing.
Concrete output: A design note and next information need.
My own project narrative
Write what you actually did and its limits in your own words rather than copying a prewritten achievement.
Ask yourself before saving
- Are assumptions separate from rules?
- Are design and execution distinguished?
- Are uncovered rules explicit?