---
title: "AI browser testing that repairs the path, not the outcome"
description: "Run AI browser tests written in plain English. agent-qa replans around UI changes, and refuses a recovery that would reach a different outcome. Source available."
canonical_url: "https://vostride.com/ai-browser-testing"
md_url: "https://vostride.com/ai-browser-testing.md"
last_updated: "2026-08-17T02:33:16+05:30"
---

# AI browser testing that repairs the path, not the outcome

> Run AI browser tests written in plain English. agent-qa replans around UI changes, and refuses a recovery that would reach a different outcome. Source available.

A web suite is the first thing a redesign breaks, because it is the only suite pinned to markup somebody just rewrote. agent-qa runs browser tests as plain-English steps against the live page and recovers from a moved control inside the same run. When no recovery reaches the step you asked for, the run fails and tells you what it found.

## The suite a redesign always breaks

Every suite pays for change. The browser suite pays first. A component library upgrade renames classes, a modal becomes a page, a checkout gains a step, and none of that changes what a customer does. All of it changes the DOM your selectors were written against. The tests go red, somebody spends a morning on locators, and the web suite becomes the thing nobody wants to own.

agent-qa holds no selectors, because it never generates a test script. Playwright is the execution kernel: agent-qa decides on each action from what is on the screen at that moment and hands the kernel a click, a fill, or a check. Nothing is recorded, so nothing goes stale when the markup does.

The file below is a complete test. It names a target, gives the runtime some context, and lists seven sentences. There is no class, no id, no data-testid, and no wait anywhere in it, which is why it still runs on a layout its author never opened.

### tests/checkout-smoke.yaml

```yaml
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.
```

## A recovery has to reach the step you asked for

Self-healing is the claim every tool in this category makes, and the fair objection to all of them is the same: a runtime that keeps trying until something goes green is a runtime that hides bugs. agent-qa draws the line at the step. When a sub-action fails, because the click was intercepted, the control moved, or the field will not take the value, it re-observes the page and plans another route to the same step, inside the same run.

What it will not do is find a different step. Take a step that asks for a $128.00 payment to be refunded in full. The refund dialog opens and reports that $35.60 of it already went back, so the button on offer refunds the remaining $92.40. Pressing that button would end the step successfully and leave the customer short. agent-qa declines it, declines the same amount typed into the field by hand, and fails the run with the reason it found.

The attempt that failed stays in the trace either way. A healed step is marked healed and carries the sub-action that did not work, so a step that needed two tries never renders as a step that passed first time. That is the part most self-healing gives up, and it is the part that decides whether a green suite is evidence or decoration.

## Chromium, Firefox, and WebKit are a setting, not a second suite

Cross-browser coverage usually means a parallel suite or a matrix nobody maintains. Here the engine is one value in the test file. All three engines run through the same kernel, so pointing an existing flow at another one costs a setting rather than a rewrite, and the steps never mention which browser they are in.

The same block carries headless, viewport, and timeouts, plus console and network capture for the flows that need those logs. A workspace default covers the suite, one test overrides it, and the --browser and --headless CLI flags beat both for a single run, which is what a CI matrix job or a local debugging pass actually wants.

A web run can also start signed in. Auth state is resolved by target and logical name, so a test asks for the qa-admin session rather than pointing at a storage-state file on disk.

### Per-test browser settings

```yaml
test-id: t_checkout-smoke
target: storefront-web
use:
  browser:
    name: webkit
    headless: true
    viewport:
      width: 1440
      height: 900
  logCapture:
    console: true
    network: false
  authState: qa-admin
```

## Frequently asked questions

### What is AI browser testing?

A runtime drives a real browser from steps written as sentences instead of from scripted selectors. An agent-qa web test names a target and lists what the user does. The runtime observes the page, decides on each action, hands it to Playwright, and checks the result. Nothing is recorded, so nothing goes stale when the markup changes.

### How is self-healing different from retrying until a test passes?

The recovery is bounded by the step. agent-qa will re-observe the page and take a different path to the outcome the step named, and it will decline a path that reaches a different outcome even when that path ends in a green button. A run with no path to what was asked fails and reports what it found, and the failed attempt stays in the trace so a healed step is never reported as a clean pass.

### Can one test run on Chromium, Firefox, and WebKit?

Yes. The engine is a value in the test's use.browser block. A workspace default applies until a suite, a test, or the --browser CLI flag overrides it, and the flag wins for that run. Because the steps never name the engine, a cross-engine check is a setting on a test you already have.

### How is agent-qa different from Playwright or Cypress?

agent-qa runs on Playwright, so this is not one browser runtime against another. A Cypress or hand-written Playwright suite is code you author and maintain: every locator, wait, and assertion is yours. agent-qa treats the runtime as an execution kernel and decides the actions itself while the run is happening. Teams usually keep scripted tests for the paths they want pinned exactly and move the flows that keep breaking over to agent-qa.

### What does a failed web run give me to debug with?

Step-level artifacts: screenshots, the sub-actions that ran and their timings, any healing attempt and the reason for it, and a failure classification. Browser console and network capture are per-test settings, so a flow that needs those logs can have them and a flow that should not depend on them can turn them off. The local dashboard shows every step and sub-action of a run.

## Related resources

- [Web testing guide](https://vostride.com/docs/agent-qa/guides/web-testing)
- [Auth state](https://vostride.com/docs/agent-qa/guides/auth-state)
- [Run dashboard](https://vostride.com/docs/agent-qa/dashboard)
- [agent-qa vs Playwright](https://vostride.com/playwright-alternative)
- [agent-qa vs Selenium](https://vostride.com/selenium-alternative)