Automated Test Runs
3 min read
A test run in Hawzu is either manual or automated. A manual run is worked through by testers who record each result by hand. An automated run delegates the work to a CI/CD pipeline: Hawzu starts the build, watches it, downloads the report it produced, and maps each result back onto the test cases in your repository.
Hawzu is not trying to be a CI/CD platform. Your pipeline still builds, deploys, and runs the tests. Hawzu treats it as an execution engine and its report as the source of truth — nothing reads your repository or makes assumptions about Playwright, pytest, Selenium, or TestNG.
The flow
Section titled “The flow”Every automated run follows the same path, whichever provider it uses.
- Trigger — Hawzu asks the provider to start a build, or you point the run at a build that already ran.
- Watch — Hawzu polls the provider until the build finishes.
- Download — Hawzu fetches the build’s artifacts.
- Parse — Hawzu detects the report format and reads the results out of it.
- Map — each result is matched to a test case and recorded as an execution result.
Each stage is reported separately, so a build whose tests failed reads differently from a build whose report Hawzu could not read. See Watch a Build for the full state list.
Supported providers
Section titled “Supported providers”| Provider | What Hawzu runs |
|---|---|
| Jenkins | A job |
| GitHub Actions | A workflow on a branch |
| GitLab CI | A pipeline on a branch |
Support is provider-agnostic by design, but only these three have adapters today. Azure DevOps, CircleCI, and Bitbucket Pipelines can still send results to Hawzu — see Pipelines That Run on Their Own and Importing CI Results.
What you need before starting
Section titled “What you need before starting”- A workspace integration for the provider, with the CI capability turned on — Actions for GitHub, Pipelines for GitLab. Jenkins integrations are CI-only. See Connect a CI Provider.
- A pipeline that emits a report in one of the supported formats.
- A way for Hawzu to tell which test case each result belongs to. See How Results Map to Test Cases.
Two ways to scope a run
Section titled “Two ways to scope a run”The choice matters, because it decides what the run can tell you.
The report defines the run. Create the run and let the pipeline fill it. Any result naming a test case code that exists in your repository is adopted into the run. Zero setup, and ideal when a pipeline simply wants its results recorded.
The trade-off: the run’s scope is whatever the pipeline happened to contain, so it can never tell you what your automation doesn’t cover.
You define the run. Add the test cases the pipeline is meant to cover before the build runs. Cases the report never mentions are left Not Executed — and that is real signal. It is the gap between what you meant to automate and what actually ran.
Pushing instead of pulling
Section titled “Pushing instead of pulling”Everything above is Hawzu pulling from your CI. If your pipelines already run on their own schedule, they can push to Hawzu instead:
- A signed inbound webhook per pipeline — see Pipelines That Run on Their Own.
- A direct API upload of the report — see Importing CI Results.