QA Runs
A QA Run is a single execution of a QA Flow. Each run executes the flow’s test cases against your application in a real browser and records a verdict for every test.
Starting a run
Section titled “Starting a run”From a QA Flow, click Run Now (or Run Again if the flow has run before) and configure the run:
- Browsers — Choose one or more of Chromium, Firefox, and WebKit. Selecting more than one runs the flow across each browser so you can compare results. You can also run browsers in parallel.
- Self-Healing options — Decide whether the run should automatically repair tests that drift, and whether to accept those repairs without review. See Self-Healing.
A run starts immediately and you’re taken to its live view. Tests update in real time as the agent works through them.
Watching a run
Section titled “Watching a run”While a run is in flight, each test moves through these states:
| Status | Meaning | |--------|---------| | Queued | The test is waiting to start. | | Running | The agent is actively executing the test in the browser. | | Passed | The application reached the expected outcome and the followed steps aligned with the plan. | | Needs Healing | The expected outcome was reached via a different path than planned — a Self-Healing candidate. | | Failed | The expected outcome was not reached. | | Stopped | The test was stopped before completing. |
The run summary shows live counts of passed, needs-healing, and failed tests, along with elapsed time. You can Stop a run at any time — in-flight tests are marked stopped.
Reading results
Section titled “Reading results”Every test is evaluated automatically against its expected outcome. The verdict explains:
- Whether the outcome was reached.
- Whether the followed steps aligned with the planned steps.
- A short, human-readable reason for the verdict.
Each test also has a walkthrough: the steps the agent actually followed and screenshots captured along the way.
Reports
Section titled “Reports”From a run you can open the report, which lays out every test with its verdict, planned steps, the steps actually followed, and a screenshot carousel. Reports can be downloaded as PDF or Markdown.
Run history
Section titled “Run history”Every run is kept, so you can compare pass rates over time and revisit the report for any past run. Runs also record their source — whether they were started manually or triggered by an automation — so you can tell apart on-demand checks from automated ones.
Triggering runs from automations
Section titled “Triggering runs from automations”QA Runs don’t have to be started by hand. They can be triggered automatically — for example, from a GitHub pull request, a Slack command, or a scheduled automation — using Connectors.