Executions and Test Runs FAQs
2 min read
These answers explain the difference between release-bound executions and standalone test runs.
What is an execution?
Section titled “What is an execution?”An execution is a testing session inside a release. A release can contain multiple executions, such as initial testing, fix validation, regression, and final sign-off.
Executions follow release status rules.
What is a test run?
Section titled “What is a test run?”A test run is a standalone project testing session. It is not tied to a release.
Use test runs for ad-hoc testing, exploratory testing, quick validation, and regression outside formal release cycles.
How do I choose test cases?
Section titled “How do I choose test cases?”Both executions and test runs can include test cases selected:
- Manually.
- From requirements.
- From test suites.
Hawzu deduplicates selected test cases where the same test case appears from multiple sources.
What result statuses are available?
Section titled “What result statuses are available?”Test cases can be marked:
- Passed
- Failed
- Blocked
- Skipped
- Not Executed
Learn more in Running Tests.
Can I assign test cases?
Section titled “Can I assign test cases?”Yes. Assignments help distribute execution work and clarify ownership.
Use assignments consistently, especially for large executions or test runs.
Where do I review analysis?
Section titled “Where do I review analysis?”Use:
- Execution Analysis for a single execution or test run.
- Defect Insights for failed test cases, linked defects, and defect pressure.
- Release Insights for release-level readiness.
Can a test run be driven by CI/CD?
Section titled “Can a test run be driven by CI/CD?”Yes. Set Type to Automated (CI/CD) when creating the run and name the pipeline that runs it. Hawzu starts the build, watches it, downloads the report, and maps the results back onto test cases. Jenkins, GitHub Actions, and GitLab CI have adapters.
If your pipelines already run on their own schedule, they can push results to Hawzu instead. See Automated Test Runs.
How does Hawzu know which test case an automated result belongs to?
Section titled “How does Hawzu know which test case an automated result belongs to?”By the test case code. Put it in the test’s name — CHK-101 user can log in — or state it explicitly in the report, for example a JUnit testcase_code property or a Cucumber @CHK-101 tag. An exact test case title match is used as a last resort.
Matching on names alone would break the moment someone renamed a test, which is why the code takes priority. See How Results Map to Test Cases.
What happens to automated results that match nothing?
Section titled “What happens to automated results that match nothing?”They are recorded against the build for reference and shown with an outcome of Not in this run or No matching test case, but they never affect status counts, analytics, test case history, or release readiness.
The Automation Health report summarises them over time, so you can see what your pipelines run that Hawzu cannot account for.
Why are some test cases still Not Executed after a build imported?
Section titled “Why are some test cases still Not Executed after a build imported?”Because the report never mentioned them. That is deliberate — it is the gap between what you meant to automate and what actually ran, and it is the reason to add test cases to an automated run before the build rather than letting the report define its scope.