Run it from the test run
Press Run and Hawzu starts the build on Jenkins, GitHub Actions, or GitLab CI — with the branch and build parameters the run was configured with. No API calls of your own.
Your pipeline already runs the tests. Hawzu makes the results mean something.
Point a test run at a Jenkins job, a GitHub Actions workflow, or a GitLab CI pipeline. Hawzu starts the build, watches it, reads the report it produced, and maps every result back to a test case — so a release decision rests on evidence, not on a green tick somebody screenshotted.
Drives JenkinsGitHub ActionsGitLab CI
Parses JUnit / xUnitTRXNUnit 3Cucumber JSONAllure
Trigger, watch, parse, map
Hawzu is not trying to be a CI platform. Your pipeline builds, deploys, and runs the tests. Hawzu treats it as an execution engine and its report as the source of truth.
- 01
Trigger
Hawzu starts the build — or you point the run at a build that already ran.
- 02
Watch
Polled on a backoff until it finishes, with the build's own state shown alongside Hawzu's.
- 03
Parse
Artifacts downloaded, zips unpacked, format detected, results read out.
- 04
Map
Each result resolved to a test case by code, and recorded as a real execution result.
Automation results a sign-off can rest on
Plenty of tools will ingest a JUnit file. The difference is what happens to the rows that don't line up — and to the tests that never ran at all.
Watched, not guessed at
Hawzu polls the build on a backoff and reports each stage separately — queued, running, downloading, parsing, importing. Your tests failing reads differently from the import failing.
Any report, no plugin
JUnit, TRX, NUnit, Cucumber, and Allure are parsed on arrival — format auto-detected, zip artifacts unpacked. Hawzu reads reports, never your repository.
Mapped by code, not by name
Each result resolves to a test case by its Hawzu code — stated in the report, or embedded in the test's title. Renaming a test doesn't quietly break the link.
Unmatched results stay quarantined
A row that matches nothing in the run is recorded and shown, but never touches status counts, analytics, test case history, or release readiness. It cannot inflate a pass rate.
What didn't run is the point
Test cases the report never mentions stay Not Executed on purpose. That gap — between what you meant to automate and what actually ran — is what a readiness dashboard needs to be honest.
Matching a test to a test case
Matching on the test's name alone is a trap — the first rename silently breaks it. So Hawzu resolves each row in order, and never guesses at an ambiguous title.
- 1
A code stated by the report
A JUnit
testcase_codeproperty, an MSTest trait, a Cucumber@CHK-123tag, an Allure label. Survives any rename. - 2
A code in the test's name
No tooling at all — just put the code in the title. One test can name several cases, and each one gets the verdict.
- 3
An exact title match
A convenient fallback for suites that were never instrumented. Ambiguous titles are left unmatched rather than guessed.
Pipelines that already run on their own
Plenty of teams don't want a test tool starting their builds. Two ways to push instead — and both land on exactly the same import path.
A signed webhook
Your pipeline tells Hawzu it finished; Hawzu fetches the report and imports it. HMAC-SHA256 signed, so the endpoint needs no session.
Post the report
One REST call with the report as the body. Format is detected, zips are unpacked — which is how Azure DevOps, CircleCI, and Bitbucket pipelines report into Hawzu today.
curl --data-binary @results.xml \
-H 'Authorization: Bearer <token>' \
'.../import/results?run_title=CI%20build%20123'Automation feeds everything downstream
An imported result is a real execution result — it counts towards coverage, flakiness, traceability, and release readiness exactly as a manual one does.
Connect a pipeline in a few minutes
Every feature is free while we're in early access — no credit card.