AI browser testing that survives your next redesign
agent-qa turns plain-English test files into real browser runs. The runtime plans each step against the live page, adapts when markup and layout change, and records what it learned — so your web E2E suite stops breaking every sprint.
Why script-based browser tests keep failing
Traditional browser automation encodes the page as it looked the day the test was written: selectors, waits, and assertions all pin an exact DOM. Every redesign, copy change, or component swap invalidates some of that encoding, and an engineer pays the repair bill. Most teams end up spending more time maintaining browser tests than writing new ones — or worse, deleting the suite.
AI browser testing inverts the contract. Instead of telling the browser where to click, an agent-qa test states what the user is doing. The runtime observes the actual page, plans the actions, executes them, and verifies the outcome. When the UI shifts, the plan shifts with it.
Browser tests in plain English
An agent-qa web test is a YAML file in your repo. Steps are natural-language sentences; context and environment variables keep it deterministic; hooks handle setup, teardown, and API-level checks. Because it's a file, it moves through pull requests and code review like everything else your team ships.
test-id: t_checkout-smoke
name: Guest checkout completes
target: storefront-web
context: |
The storefront runs at the URL configured by the storefront-web target.
Product data is seeded by the workspace setup hook.
steps:
- Open the home page and search for "espresso grinder".
- Open the first search result.
- Add the product to the cart.
- Start checkout as a guest.
- Fill the shipping form with the workspace test address.
- Place the order.
- Verify the confirmation page shows an order number.Runs that get smarter, not staler
Every run writes file-backed memory: how navigation actually works, which flows have quirks, what changed since last time. The smart cache reuses proven action plans for unchanged steps, cutting token usage and run time. Failures come back as step-level artifacts — screenshots, logs, classification — that a human or a coding agent can triage immediately.
The same test runs from a laptop, a CI job, or a coding agent via MCP, with identical behavior and evidence. No hosted grid, no per-session pricing, no vendor cloud in the loop.
# initialize a workspace
npx agent-qa init
# run a test
npx agent-qa run tests/checkout-smoke.yaml
# inspect runs in the local dashboard
agent-qa dashboard --port 3470 --openFrequently asked questions
What is AI browser testing?
AI browser testing uses a model-driven runtime to execute tests expressed as user intent rather than as scripted selectors. With agent-qa, you write steps in plain English; the runtime plans real browser actions against the live page, verifies outcomes, and adapts when the UI changes.
How is agent-qa different from Playwright or Cypress for browser testing?
Playwright and Cypress are excellent script engines — you program every action and maintain the selectors. agent-qa operates a layer above: intent in YAML, actions planned at runtime, self-healing on UI change, and memory across runs. Many teams keep a thin scripted layer and move flow coverage to agent-qa.
Does AI browser testing work in CI?
Yes. agent-qa runs headless in CI with the same command used locally, and its cache reuses known-good action plans so repeat runs are fast and inexpensive. Artifacts and failure classifications publish with the build.
Which browsers does agent-qa support?
Tests target real browser runtimes (for example Chromium) configured per test or per workspace, with viewport and headless options controlled in YAML.
Is agent-qa free for browser testing?
agent-qa is open source with no paid tier. You pay only for LLM tokens from the provider you configure — reduced by plan caching — and run on infrastructure you already own.