Practical guidance for getting standalone test runs right. For the workflow itself, start with Test Runs Overview.
Plan The Run
Section titled “Plan The Run”- Use a clear title that explains the goal, not just the date.
- Keep the description focused on what is being validated.
- Choose only the test cases the scope needs — a run padded with irrelevant cases makes its pass rate meaningless.
- Use requirements and test suites when they make the selection easier to maintain than a hand-picked list.
Record Useful Results
Section titled “Record Useful Results”- Keep statuses accurate as testing progresses, rather than filling them in at the end.
- Add notes at the step where the issue happened, not on the test case as a whole.
- Attach evidence for failed and blocked work.
- Distinguish Failed from Blocked honestly. A blocked test tells you nothing about whether the feature works, and treating it as a failure hides that.
- Review skipped and not-executed test cases before treating the session as complete.
Complete Runs Deliberately
Section titled “Complete Runs Deliberately”Completing a run locks it and freezes its defect-derived analytics. That is what makes a finished run safe to cite later — the numbers cannot drift when defects change afterwards.
Resume rather than delete when a run needs one more result. See Complete and Resume.
Automate The Repeatable Parts
Section titled “Automate The Repeatable Parts”A suite that runs the same way every time is a candidate for an automated run.
When you do automate:
- Add the test cases to the run before the build. Cases the report never mentions stay Not Executed, and that gap is the whole point — a run whose scope is whatever the pipeline happened to contain can never tell you what your automation misses.
- Put the test case code in the test’s name. It survives renaming in a way title matching does not.
- Check Automation Health periodically. Tests your pipeline runs that map to no test case are traceability you think you have and do not.
Use The Right Workflow
Section titled “Use The Right Workflow”Use Test Runs for independent testing outside a release.
Use Release Executions when the work belongs to a release milestone and should contribute to release progress and readiness. Choosing a test run for release-bound work means the release dashboard will not know the testing happened.