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
Test runs and release executions
Section titled “Test runs and release executions”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 Runs | Release Executions | |
|---|---|---|
| Lives in | A project | A release |
| Affects release progress | No | Yes |
| Affects release readiness | No | Yes |
| Blocked by release status | No | Yes — paused, completed, and archived releases block work |
| Best for | Standalone testing outside releases | Release-bound testing cycles |
If the work should count towards a milestone’s go/no-go decision, use a Release Execution instead.
Manual and automated
Section titled “Manual and automated”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.
The Test Runs page
Section titled “The Test Runs page”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.
What test runs do not do
Section titled “What test runs do not do”Test runs do not:
- Belong to a release.
- Change release progress.
- Change release readiness.
- Group multiple release cycles under one milestone.