A test case may make sense to its author and still leave a teammate with questions. Which account should they use? Where should they start? What counts as a pass? A shared format gives these details a regular place, so the next person can find them.
The key idea
Start with the conditions, steps, and expected result. Keep each detail in a consistent place so teammates can run the test and judge the result without having to ask the author.
What is missing from “the user can log in”?
This sentence leaves out the account, the starting screen, and the result to check. Write those details down, even if they seem obvious when you are preparing the case.
Here is an example for a fictional login feature. Use your own specification to decide the expected result and test data.
| Field | Example |
|---|---|
| Purpose | Check that an active standard user can log in |
| Preconditions | The user is registered and their account is available for use |
| Data | Valid credentials for a test account |
| Steps | Open the login screen, enter the credentials, and submit |
| Expected result | The account page opens and displays the correct username |
| Execution record | Record the actual result, verdict, environment, and supporting evidence |
Include the details needed for review and investigation
A consistent format makes it easier to notice a missing precondition or an expected result that is too vague. It also helps someone new to the feature find what they need to run the test.
These details are useful when a test fails, too. Keep the environment, data, steps, expected behavior, and actual behavior together so the investigation can begin with fewer follow-up questions.
- Link each case ID to the relevant specification
- Keep expected and actual results separate
- Agree on what verdicts such as Pass, Fail, and Blocked mean
- Add links to evidence and defect records
Adjust the format for the testing you are doing
Some testing needs a different format. For exploratory testing, a charter can describe the purpose, scope, and risks. Performance testing needs details such as load conditions and response times.
Keep the fields you have in common, such as purpose, target, and results. Then add the details each activity needs. You do not have to fit every kind of testing into the same step-by-step template.
Try the format on one feature first
Pick a few existing cases and look at where people get stuck when running or reviewing them. Use those examples to choose the fields you need, then try the format on one feature.
Afterward, ask whether people had fewer questions and how much effort it took to write the cases. You can update older cases when you next use them, rather than rewriting everything at once.
QA Notebook / Test design
Read nextData-driven testing explained with an input formBack to all articles