Start with observable results
| Case | Precondition | Action | Expected result | Status |
|---|---|---|---|---|
| Duplicate invoice | Invoice already imported | Import the same identity again | One invoice remains; duplicate is recorded | Not run |
| Missing currency | Invoice has no currency | Attempt import | Review is required; no accounting record is written | Not run |
| Booking conflict | The selected room is occupied | Request the same time | Conflict is shown and no second booking is confirmed | Not run |
| Role restriction | A read-only user is signed in | Attempt to edit a record | Change is refused and the original record remains | Not run |
Replace the examples with your agreed user journeys. Add the actual result, evidence reference, owner and decision date in your working copy. A pass means the agreed result was observed; it does not mean every feature of the product has been tested.
Record failure without rewriting the expectation
When a result differs, record what happened and the smallest steps that reproduce it. Decide whether it is a defect or a new requirement before changing the expected result. After a repair, repeat the affected case and a relevant neighbouring case, such as a valid import after a rejected one.
For scenario-based specifications, Cucumber’s Gherkin reference distinguishes the initial context, an event and an observable outcome. You can use that structure in a spreadsheet without adopting Cucumber or claiming that the sheet is an automated test suite.