Skip to content

Test Runs Best Practices

2 min read

Practical guidance for getting standalone test runs right. For the workflow itself, start with Test Runs Overview.


  • 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.

  • 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.

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.


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 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.