Skip to content

Test Runs Overview

2 min read

A test run is a standalone testing session inside a project. It gathers a set of test cases, records a result for each, and reports on how the session went — without belonging to a release.

Use test runs when the testing is not part of a release milestone:

  • Ad-hoc validation
  • Exploratory testing
  • Focused regression
  • Sprint checks
  • Quick verification after a fix
  • Any suite driven by CI/CD

Hawzu has two testing workflows. They share the same test cases, the same result statuses, and the same analysis views — what differs is what they belong to and what they affect.

Test RunsRelease Executions
Lives inA projectA release
Affects release progressNoYes
Affects release readinessNoYes
Blocked by release statusNoYes — paused, completed, and archived releases block work
Best forStandalone testing outside releasesRelease-bound testing cycles

If the work should count towards a milestone’s go/no-go decision, use a Release Execution instead.


Every test run is created as one of two types.

Manual — worked through by testers, who open each test case, run it, and record the result by hand. See Running Tests.

Automated (CI/CD) — driven by a pipeline. Hawzu triggers the build, watches it, downloads the report it produced, and maps each result back onto the run’s test cases. There is nothing to record by hand. See Automated Test Runs.


Open Test Runs in a project to see every run it contains, with progress, status counts, and the usual search, filter, and sort controls. There is also a workspace-level view for looking across projects.

From a run you can open its details, add or change test case sources, record results, review Analysis, and export a sign-off report.


Test runs do not:

  • Belong to a release.
  • Change release progress.
  • Change release readiness.
  • Group multiple release cycles under one milestone.