QAwalk

All guides › By use case

By use case

Regression before a release: compare the run with the accepted baseline

Run the flows against staging, compare with the baseline run the team accepted, and see what moved: step statuses, criteria, evidence, pixels.

Three agents, four branches, one staging, zero memory of what changed. Before a release we want one answer: what looks different from the version we accepted, and is it on purpose.

The problem

Regression suites tell us whether the code still passes. They do not show us the screens, and they do not know which differences a person would care about. So we open staging, scroll, and hope.

What changes with QAwalk

A run the team accepted becomes the scenario's baseline. Every later run can be compared with it on the canvas: pixel differences per step, criteria whose verdict or evidence changed, added or removed steps. The same comparison prints as text for the agent and the release notes.

How it works

  1. Accept a baseline

    on a good run the reviewer presses *Accept run* and *Set as baseline*. One baseline per scenario.

  2. Run the flows against staging

    qawalk start --scenario qa/flows/checkout.yml --env staging, qawalk walk, qawalk evaluate, qawalk share. Test data belongs to the staging prepare step; the scenario creates only what it needs.

  3. Compare

    on the canvas choose *Compare → baseline*: badges with the share of changed pixels per step, Δ on changed criteria, side-by-side and diff views in the lightbox. In the terminal qawalk compare prints the same.

  4. Decide

    intended changes become the new baseline; unintended ones go back as returned steps with notes.

Skills and prompts

Run every flow in qa/flows against staging, compare each with its baseline and list what changed with the evidence. Do not accept anything.

Expected outcome: shared runs per scenario, a text diff per scenario (statuses, verdicts, evidence), canvas links with #cmp=<baseline>.

Explain the differences between run A and its baseline in two sentences per changed step, for the release notes.

Expected outcome: a short list the agent derives from qawalk compare --json; nothing invented, every line points at a step.

What you get

FAQ

Are small rendering differences noise?

Fonts and anti-aliasing move a few tenths of a percent; the badge shows the share so you can ignore it. Masks for dynamic regions are on the roadmap.

Can I compare two arbitrary runs?

Yes: the *Compare* selector lists the baseline, the previous run and other runs of the scenario; #cmp=<run id> in the URL shares the view.

What it looks like

A real run of QAwalk on its own public pages, refreshed daily. This is the canvas your team gets.

6 of 6 steps passed · 2026-09-24Open the run in QAwalk ↗

More guides

Accepting a task with an AI agent, in the pull requestSEO and landing-page checks on production, read-only, every dayE-mail flows: capture the message next to the screen that sent it

Install in three steps

QAwalk runs where your code and your agent are. The service stores and versions the results, shows the canvas and collects approvals.

  1. Add the CLI to the project
    npm install --save-dev github:sinfin/qawalk#v0.1.0

    Pre-launch: the repository is private. Ask Sinfin for access.

  2. Create the config and install the skill
    npx qawalk init --agent claude --org <your-org>
    npx qawalk doctor

    The skill is copied to .claude/skills/qawalk.

  3. Create your organization and a token

    Create an organization; you become its admin. The start page offers a tester token in one click, later under Settings → API tokens. Put it into the project .env:

    QAWALK_TOKEN=qwk_…
    TYPESAFE_API_KEY=…   # optional: semantic evaluator
  4. Run and share
    npx qawalk start --scenario docs/tasks/TASK-123/qa/scenario.yml --env local
    npx qawalk walk        # playwright steps; agent/manual steps: qawalk capture
    npx qawalk evaluate
    npx qawalk share --pr

    Or ask your agent: “Walk the acceptance plan of TASK-123 with QAwalk on local and share the result.”