Zerocheck

Get your first test running

1. Connect your repo

Paste your staging URL and connect your GitHub repository. Project settings live in Zerocheck, and local .yaml files can be used as editable test-case working copies for the CLI.

Staging URL:  https://staging.yourapp.com
Repository:   github.com/yourorg/app
Status:       Connected ✓

2. Review your generated tests

Zerocheck scans your app and proposes tests built from critical flows. Review suggested tests on the Suite page, edit anything that needs adjusting, and approve the ones you want to run. PR-diff tests are also saved as suggestions until reviewed.

version: zerocheck/v1
name: "Checkout page loads"
flow: "Checkout"
critical: true
blocks_merge: true
steps:
  - Navigate to /checkout
  - Verify the checkout page is visible
  - Verify the order summary is visible

3. Run on a pull request

Push a PR. Zerocheck runs the active approved suite against staging, analyzes the diff for coverage gaps, and posts results as a PR comment. Any tests generated from the diff are saved as suggestions for review.

zerocheck  bot  ·  2 min ago

  Approved suite
  ✓ Complete purchase flow          1m 52s
  ✓ Subscription renewal flow       0m 38s
  ✓ User signup and onboarding      1m 03s

  3 passed · 0 failed · 3m 33s

  Suggested tests
  • Failed-payment retry            saved for review

  Suggested tests were not run on this PR and do not affect
  the status check until approved.

4. Review evidence artifacts

Executed browser runs produce timestamped JSON evidence bound to the commit SHA, with per-test recordings, screenshots, and a step trace.

Next: Write tests in plain English

Write tests in plain English

Test spec format

Each test case is a small YAML document. The header carries a name, the flow it belongs to, whether it is critical, and whether it should block merge when approved. The steps list is plain English — each step describes what a user would do, not how to locate an element.

version: zerocheck/v1
name: "Billing page shows current plan"
flow: "Billing"
critical: true
blocks_merge: true
monitor:
  every: 30m
steps:
  - Navigate to the billing page
  - Verify the current plan is visible
  - Verify the billing history is visible

You can edit this in a form view on the dashboard — the fields (name, flow, critical, merge blocking, monitor interval, steps) map one-to-one to the YAML. Toggle to the YAML tab for full control, or import YAML files from disk.

Visual interaction

Zerocheck uses the browser's accessibility tree to find UI elements by their visible label and ARIA role, the same way a real user would. You don't add data-testid attributes or maintain CSS selectors.

When your UI changes (button moves, class name changes, component gets wrapped in a new div), tests usually still pass because the element is still identifiable by its label. You maintain tests when the visible intent of the UI changes, not when the implementation does.

page.locator('#btn-checkout').click()
page.locator('div.cart > span.price')
page.locator('[data-testid="iframe"]')

Click the "Checkout" button
Verify the cart total is correct
Verify the confirmation page appears

Usually survives CSS refactors, component renames, and redesigns when element labels stay consistent.

PR-diff awareness

When a PR modifies CheckoutForm.tsx and CartSummary.tsx, Zerocheck analyzes the diff to identify affected flows and possible coverage gaps. The PR check still runs the active approved suite against staging; diff-generated tests are saved as suggestions for review.

Files changed:
  src/checkout/CheckoutForm.tsx   +42  -18
  src/checkout/CartSummary.tsx    +15  -7
  src/lib/billing.ts              +3   -1

Zerocheck analyzed diff → 2 affected flows:
  → Checkout         covered by approved test
  → Billing          suggested test saved for review

Approved suite: 47 passed · 0 failed
Suggested tests: 1 awaiting review

When a flow is uncovered

If your change touches a flow that has no approved test, Zerocheck saves a suggested test for review. Suggested tests are non-blocking, are not run on the current PR, and do not count toward coverage or merge gating until a user approves them. You can edit, approve, or delete them from the dashboard.

Approval and merge gating

Approved tests can set blocks_merge: true when a failure should fail the PR status. Approved non-blocking tests are reported without failing the check. Suggested tests never block merge until a user reviews and approves them. Tests fail closed: when a step can't confidently identify an element, the test fails instead of silently passing.

Payment and sensitive flows

Zerocheck can run approved customer-authored browser tests against safe staging or test environments. Generated and discovery tests avoid payment fields, final purchase actions, file uploads, and destructive account actions until a user explicitly authors and approves the flow.

version: zerocheck/v1
name: "Checkout page loads"
flow: "Checkout"
critical: true
blocks_merge: true
steps:
  - Navigate to /checkout
  - Verify the checkout page is visible
  - Verify the order summary is visible

Next: Run tests on every PR

Run tests on every PR

How results appear

Zerocheck posts a comment on every pull request, led by a coverage summary and followed by a per-test results table, step trace, screenshots, and a link to each run recording.

zerocheck  bot

  ┌──────────────────────────────────────────────────────────┐
  │  Coverage for this change                                │
  │    ✓ Checkout     covered by "Complete purchase flow"    │
  │    ✓ Billing      covered by "Subscription renewal"      │
  │    ✓ Signup       covered by "User signup and onboarding"│
  ├──────────────────────────────────────────────────────────┤
  │  3 passed · 0 failed · 8m 12s                            │
  ├──────────────────────────────────────────────────────────┤
  │  ✓  Complete purchase flow      ▶ Recording    2m 14s   │
  │  ✓  Subscription renewal        ▶ Recording    0m 38s   │
  │  ✓  User signup and onboarding  ▶ Recording    1m 03s   │
  ├──────────────────────────────────────────────────────────┤
  │  View screenshots · View step traces          [JSON]    │
  │  Commit a3f7c2e                                          │
  └──────────────────────────────────────────────────────────┘

When every affected critical flow is covered, the coverage block is celebratory. When one or more are uncovered, the comment leads with the list of uncovered flow names — never a percentage. You know immediately what needs attention.

Merge gating

Zerocheck can be set as a required status check on your repository. The check fails only when an approved test with blocks_merge: true fails. Non-blocking approved failures are reported without failing the check. Suggested tests from a PR diff do not run or block until approved.

Failure details in the PR comment

When a test fails, the PR comment expands a "Failure details" section with the failing step, the error message, and a screenshot of the failure state. Everything you need to reproduce the failure is in the PR thread — no separate bug tracker integration needed.

Continue running after merge

After a production URL is configured, approved critical tests can keep running against production. Non-critical approved tests monitor only when they set monitor.every. You can detect deployment regressions and third-party outages at the flow level instead of waiting for a user report.

version: zerocheck/v1
name: "Admin dashboard loads under 3s"
flow: "Admin"
critical: true
blocks_merge: false
monitor:
  every: 5m
steps:
  - Navigate to the admin dashboard
  - Verify the metrics panel is visible

A single failure triggers an immediate re-run. Alerts fire through Slack after the configured consecutive-failure threshold.

What connects to Zerocheck

Don't see your tool? Suggest an integration.

Next: Evidence & audit trail

Evidence & audit trail

Run recordings and screenshots (proof of execution)

Every test run captures a full recording of the browser session as proof of what happened. Each test gets its own recording, plus per-step screenshots (before and after each action). Failed steps include a highlighted screenshot of the failure state. Recordings and screenshots are linked in PR comments, evidence artifacts, and the dashboard.

Evidence artifacts

Every executed run writes a structured JSON artifact bound to the commit SHA and timestamped at run start. The artifact lists each test that ran, its outcome, duration, recording URL, screenshot count, and step trace. The current export is JSON run evidence; compliance teams can map that raw proof to audit needs outside Zerocheck.

{
  "artifact_id": "c4f7a2e-8b1d-4a3e-9f2c-5d8e7a1b4c6d",
  "commit": "a3f7c2e",
  "timestamp": "2026-04-20T00:14:32Z",
  "repository": "acme/web-app",
  "confidence_score": 0.94,
  "tests": [
    {
      "name": "Checkout page loads",
      "result": "pass",
      "duration_ms": 34210,
      "recording_url": "/artifacts/run-123/videos/checkout.webm",
      "screenshot_count": 6,
      "step_trace": [
        { "step": 1, "action": "Navigate to /checkout", "result": "pass" },
        { "step": 2, "action": "Verify the checkout page is visible", "result": "pass" }
      ]
    }
  ]
}

Next: Reference

Reference

Test case YAML fields

Step keywords

Evidence export

Local YAML working copies

Most project configuration lives in Zerocheck. The CLI can still validate and run local .yaml test-case files while you edit, generate, or import tests.

version: zerocheck/v1
name: "Billing page smoke"
flow: "Billing"
critical: true
blocks_merge: true
monitor:
  every: 30m
steps:
  - Navigate to the billing page
  - Verify the current plan is visible
  - Verify the billing history is visible