Working with Steps and Expected Results
In QAM Hub, each test case is built from steps — the actions a tester performs — and expected results — what should happen at each point. Writing these clearly is what makes a test case repeatable: any tester should be able to follow the steps and know exactly whether the test passed or failed.
This guide covers how to add steps and expected results to a test case, attach supporting images, and write them well. If you have not created a test case yet, start with creating test suites and test cases.
Adding steps and expected results
- Open a test case in your project, or create a new one inside a suite.
- In the Steps block, describe the actions the tester should take, in order.
- In the Expected Result block, describe what should happen — the observable outcome that tells the tester the step succeeded.
- Save the test case. Every change is captured in its version history, so you can roll back if needed.
Attaching images to steps and expected results
You can attach screenshots directly to the Steps and Expected Result blocks — useful for showing a starting state, a UI element to interact with, or what a correct result looks like.
A few limits to keep in mind:
- Each block (Steps and Expected Result) supports up to 5 images, with a maximum of 10 images per test case.
- Image captions can be up to 200 characters.
- Images can be reordered by dragging them into place.
- You can upload a new image or reuse one from the project Library via "From Library."
Writing clear steps and expected results
Good steps and results make a test case usable by anyone, not just its author. A few practical guidelines:
- One action per step. Keep each step to a single, concrete action so results are unambiguous.
- Make expected results observable. Describe something the tester can actually see or verify, not an internal assumption.
- Avoid vague wording. "Page works correctly" is hard to verify; "Order confirmation message is displayed" is clear. QAM Hub's Quality Analyzer can flag vague titles to help with this.
- Stay tool-independent where possible. Write what to verify, not how a specific build happens to render it, so the case survives minor UI changes.
Reusing structure with templates and custom fields
If many of your test cases follow the same shape, you can standardize them with test case templates and capture extra structured data with custom fields, rather than repeating the same setup by hand each time.