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 a CI/CD platform. Your pipeline still builds, deploys and runs the tests. Hawzu reads your pipeline’s test report. It doesn’t read your repository or need to know whether you use 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 checks the build regularly until it 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 |
Supported today: Jenkins, GitHub Actions, GitLab CI. Other CI tools, such as Azure DevOps, CircleCI and Bitbucket Pipelines, can still send their reports to Hawzu with 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 added to 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.
Pipelines that run on their own schedule
Section titled “Pipelines that run on their own schedule”Everything above is Hawzu starting a build and checking it. If your pipelines run on their own schedule, or Hawzu didn’t start the build, upload the report with Importing CI Results.
For builds Hawzu did start, your CI can also notify Hawzu when they finish, so results arrive sooner. See Pipelines That Run on Their Own.