Documentation
Understand what happened in a test run
Zerocheck records the exact test definition and revision that ran, the selected environment and browser location, and the outcome of each attempt. Start at the failing step, then inspect the evidence around it.
A failed outcome and an incomplete run are different
| Result | What to do next |
|---|---|
| Passed | Review that the test and expected outcome cover the flow you intended. |
| Failed expected outcome | Inspect the assertion and browser state to investigate the behavior. |
| Needs input during import | Supply the missing setup, credential reference, fixture or expected outcome. |
| Could not run | Inspect the setup, interaction or service error; the requested flow has not been verified. |
| Passed on retry / flaky | Inspect the transient recovery and apply your team's merge policy. |
Runs can be queued, running, passed, failed, error or cancelled. A saved failing test remains failing; saving or editing a definition does not produce a new passing result.
Evidence you can inspect
Run detail shows per-step results, before-and-after screenshots, error text, console warnings and errors, recovery notes and healing history. Failed steps expand by default. Every attempt retains its steps. If an artifact could not be captured, its error is recorded.
Video is recorded only when the environment has no configured secrets, because those values cannot be masked in recordings. Network responses can support assertions but are not stored as a network log. The result records how a step was resolved: directly, from a cached target, or using AI.
How healing works
Zerocheck reuses a remembered target only while it still identifies the intended control. When that control moves, the agent can resolve it again from the step's description. The history shows the old target, replacement, reason and validation state.
A heal is saved as verified only when the complete unchanged test passes with independent evidence that the intended target, action and outcome were preserved. Otherwise it stays pending, or is rejected when the test fails. There is no additional run solely to confirm a repair.
A renamed control or a changed expected outcome needs review. Healing does not give the agent permission to rewrite your product's expected behavior.
How retries work
A transient AI-service error can be retried once during a step in the same browser. If the test then passes, it is labelled flaky. Assertion, configuration and policy failures are not retried into passing results.
The shipped local and hosted runners do not blindly restart a whole test after application actions. This avoids repeating writes without a verified reset of test state. Configure retries as zero or one, and use --fail-on-flaky in the CLI when that outcome should fail a blocking test's merge policy.
Where results appear
Hosted runs appear in the web app. CLI runs upload results and artifacts so you can inspect them there too. The terminal summarizes outcomes and links to results; JSON includes the full run. GitHub Actions can add a job summary and one updated pull request comment.
Try your own customer flow.
Free seven-day assisted evaluation. No credit card.