Changing input values is enough to describe some tests. Other tests depend on the order of actions or the state of a reservation or application. Start by identifying what could cause a problem, then choose a format that makes those conditions easy to see.
The key idea
Use a data table to compare inputs, a scenario to follow a user task, and a state transition model to check what an action does in each state. A feature may need more than one of these.
Compare input variations in a table
A data table works well when the steps stay the same and the values change. Input validation is a common example: you can compare valid, missing, and out-of-range values side by side.
If you start adding many conditional actions to the table, it can become hard to tell what happens in each test. Keep the shared steps simple enough for someone else to follow.
Show the sequence of actions and the starting state
For a user task, write a scenario with preconditions, actions, and outcomes. If you are testing an application or a reservation, include its starting state. That state can change which actions are available and what they should do.
| Difference to examine | Possible representation | Example |
|---|---|---|
| Input values | Shared steps plus data | Missing required fields and length boundaries |
| Business flow | Scenario | User actions from submitting an application to approval |
| State and action | State transition | Trying to cancel a reservation that is already canceled |
| Conditions that must always hold | Property | A calculation stays within the range defined by the specification |
Check calculation examples and rules that should always hold
For a discount calculation, you can test a specific input and expected output. You can also check a property such as “the discounted amount never falls below zero”—as long as the specification actually requires it.
A specific example checks a known result. A property checks a rule that should hold across inputs. Using both lets you check different aspects of the calculation.
Three questions before choosing an approach
It helps to think about the person reviewing the test and the person investigating a failure. They should be able to tell what was checked and under which conditions.
- Does the risk depend on input values, action order, or combinations of states?
- Which specification or other evidence tells you whether the result is correct?
- When a test fails, can we identify the conditions under which it failed?
QA Notebook / Test design
Read nextStarting a new team: what to decide before making templatesBack to all articles