What Is a QA Agent?

Definition

A QA agent is software that tests a running application the way a person would. It reads a plain-English step, looks at the live page, chooses an action, performs it in a real browser and checks the outcome, recording evidence for every step. It performs testing work; it does not own quality.

Why it matters

Coding agents now write more code than a team can check by hand, and selector-based suites break on the first refactor. A QA agent absorbs the two costs that stall end-to-end testing: writing the automation and keeping it working. The useful buying question is which work the agent performs and what evidence it produces. Requirements, fixtures and release decisions stay with people.

How teams handle it today

Teams evaluate a QA agent on one real flow with an explicit expected outcome. They read the generated test, run it twice, introduce a deliberate failure and check that the result explains what happened. They also ask what the agent needs from them: a URL and a test account, or repository access and preview deployments.

How Zerocheck approaches it

Zerocheck is a QA agent for web apps. You describe a flow or import your release checklist; it drafts one test per item, runs it in Chromium and records the evidence. A model proposes one action at a time from a screenshot and the accessibility tree, and a controller checks the target and permissions before the browser executes it. Expected outcomes stay fixed. Healing re-identifies an equivalent target and is saved only after the whole test passes again; it never changes an assertion to make a test pass.

Start in the web app with a hosted browser, or use the CLI on your machine, in GitHub Actions or through MCP from Claude Code or Cursor. Tests are plain YAML you own.

What a QA agent does, and does not do

A QA agent does four things on every step, and a good one shows its work for each of them:

• Reads the step and the live page. It works from a screenshot and the accessibility tree, not from a CSS selector someone wrote last quarter.
• Chooses and performs one action in a real browser: navigate, click, type, select, press. The action still waits for the control to be visible, stable and enabled, the checks Playwright documents as actionability.
• Checks the expected outcome the author wrote, such as a visible confirmation, a URL or a network response.
• Records evidence: a screenshot per step, the action it chose, any retry, and any healed target with its old and new identity.

It does not decide what to test, invent expected outcomes, create test accounts, seed data, or judge whether a failure is a bug or a bad requirement. When a product page promises "no tests to write or maintain", ask which of those jobs moved to the agent and which quietly moved to you.

What you supply, and what it produces

Nothing on the left is optional. A QA agent that starts without an expected outcome is exploring, not testing.

Four levels of QA agent autonomy

Vendors describe very different products with the same two words. This ladder sorts them by what the agent decides on its own.

Zerocheck sits at run and heal. Exploration is useful for bug bashes. It does not replace the release checklist your team already trusts, because it cannot know what the product is supposed to do.

A worked example: a medical certificate request that ends in a Stripe checkout

A leading Australian telehealth company sells medical certificates through a multi-step form: leave type, symptoms, patient details, address, review, then payment in an embedded Stripe checkout. The release checklist item reads "a new patient can request a certificate and pay". This is the test Zerocheck is running for it, with Stripe's public test card and a fresh identity on every run; the final step names the app's own confirmation label. The environment names the app URL; the embedded payment frame needs no origin configuration.

# zerocheck.yaml
environments:
  staging:
    url: https://staging.example.com/request/medical-certificate

# checks/certificate-purchase.yaml
version: zerocheck/v1
name: New patient requests a certificate and pays
description: Staging only. Public Stripe test card. Fresh identity on every run.
steps:
  - Navigate to {{app_url}}
  - Verify text "Medical Certificate Request" is visible
  - Click "Sick Leave"
  - Click "Work"
  - Click "Continue"
  - Click "Common cold or flu"
  - Click "Continue"
  - Verify text "Leave Details" is visible
  - Click "Continue"
  - Enter "Automated test request with fictional data." into "Share a few details"
  - Click "Continue"
  - Enter "{{unique_email}}" into "Email"
  - Enter "Zerocheck" into "First Name"
  - Enter "Test" into "Last Name"
  - Enter "01/01/1990" into "Date of Birth"
  - Enter "0491570006" into "Mobile Number"
  - Click "Continue"
  - Enter "1" into "Street Number"
  - Enter "Test Street" into "Street Name"
  - Enter "Sydney" into "City/Suburb"
  - Select "New South Wales" from "State/Territory"
  - Enter "2000" into "Postal Code"
  - Click "Continue"
  - Verify text "Review Your Details" is visible
  - Click "Continue"
  - Verify text "Payment" is visible
  - Verify text "Test Mode" is visible
  - Enter "4242424242424242" into "Card number"
  - Enter "12 / 34" into "Expiration"
  - Enter "123" into "CVC"
  - Enter "Zerocheck Test" into "Cardholder name"
  - Click "Subscribe"
  - Verify text "Request submitted" is visible

What the run report shows

Every step gets a screenshot, and the test finishes passed, failed, flaky (passed after a transient retry) or incomplete. If a control on the app's own pages moves, the heal is recorded with its old and new target and stays pending until the whole test passes again; targets inside the payment frame are re-identified on every run instead. If the provider's bot protection blocks the frame, the run does not pass, and the step's screenshot and recorded error show why instead of a silent timeout. A pass after a transient retry is labeled flaky, never hidden. The run verdict is what the merge policy gates on: the CLI exits non-zero and one pull request comment is updated.

As of 22 September 2026 the card step of this flow is being verified against the provider's embedded frame; the recorded run will be published here when it passes. Third-party payment processing, 3D Secure challenges and webhooks stay outside the browser test. Read how to test Stripe checkout before release for the full checklist.

QA agent, test framework, managed service, coding agent or generated suite?

The rows buyers ask about first are the last three. If you cannot grant repository access or do not have preview deployments, a codebase-driven suite is not available to you yet. If you need a pass you can replay next week, a chat session with a browser is not a test.

How to evaluate a QA agent: ten questions

1. Show me the evidence for one passing step: a screenshot and the action taken, not a green tick.
2. What may the agent change on its own? Targets only, or assertions and expected outcomes too?
3. When a heal happens, where are the old target, the new target and the validation state recorded?
4. What happens to a pass after a retry? It should be visible as flaky, not counted as green.
5. What leaves my machine, and which secrets does it read?
6. Which origins can it interact with, and can a test instruction widen that?
7. How does CI gate on it: exit codes, a required check, a comment?
8. What format are the tests in, and can I take them with me?
9. What does it cost per run, per seat or per month, and what is metered?
10. What does a failure look like on a Monday morning? Run one deliberately broken flow before you decide.

Sources

• Playwright actionability checks, read 22 September 2026.
• Stripe testing documentation, read 16 September 2026.
• Momentic: Mo, the AI QA and Momentic pricing, read 21 September 2026.
• Autonoma, including its pricing section, read 21 September 2026.
• QA Wolf pricing, read 16 September 2026.

Frequently asked questions

Related terms