How does Validate.QA avoid brittle selectors?

It scores every element's candidate locators against a 9-tier preference order — test-id and ARIA role first, raw CSS paths only as a last resort — and picks the most stable one available. It also down-ranks known traps, like name-based locators on text inputs (which change as the user types) and auto-generated-looking test-ids. Accessibility-first locators survive redesigns far better than CSS chains.

How are assertions actually 'proven'?

During generation the agent checks each candidate assertion against the live DOM of your running app and only keeps the ones that genuinely hold. After a flow's main action it re-snapshots and verifies a real post-condition — new content, a persisted value, a changed URL — so a click that silently failed can't pass as green. Every test is then executed end-to-end with native Playwright before it's trusted.

Won't tests still be flaky on dynamic data like IDs and timestamps?

A quality gate classifies each assertion by how stable it is and rejects ones pinned to ephemeral or per-run values, replacing them with durable alternatives — a stable heading, a structural element, or a regex over the variable part. The goal is checks that mean something and stay green across runs.

What happens when my UI changes and a test breaks?

When a selector drifts, the self-healing pass re-walks the flow against the live app, re-discovers the correct locator, and rewrites the affected step, then re-runs to confirm. A cosmetic change keeps the suite green instead of going red, and a test that can't be confidently healed is flagged for review rather than silently altered.

Do I own the generated tests, or are they locked into a platform?

You own them. Output is standard @playwright/test .spec.ts committed to your repository. There's no DSL, runtime SDK, or proprietary format — run the suite with npx playwright test in your own CI, with or without Validate.QA.

Which framework and browsers do the tests use?

Tests are generated for Playwright and run in Chromium during exploration and verification. Because the output is plain Playwright, the same specs run across Playwright's supported browsers in your CI.

UI testing

Most AI test tools guess at selectors and write assertions that only check 'something rendered.' Validate.QA explores your running app, ranks every locator by how well it will survive a redesign, and proves each assertion against the live DOM before it commits a single line.

Mechanism: Live exploration → ranked accessibility-first selectors → assertions proven against the running DOM, then verified by a native Playwright run.

The problem: Brittle selectors: a redesign renames a CSS class or reorders the DOM and silently breaks half the suite. Meaningless assertions: toBeVisible() on stale chrome passes even when the API 500'd and the real action never happened. Flaky assertions on dynamic data: tests pinned to timestamps, generated IDs, or user content go red on every run for no real reason. Maintenance debt: hand-written UI tests rot faster than they pay back the time spent writing them.

Explore the running app — A headless Chromium agent walks your app from a start URL — navigating pages, filling forms, opening dialogs, following links — and builds a map of every page and the transitions between them. It works from the live app, so it covers what your UI actually does, not a static spec of what it's supposed to do.

Snapshot the accessibility tree — At each state the agent captures a structured accessibility-tree snapshot — roles, names, labels, and relationships — rather than scraping raw HTML. This is the same view assistive technology sees, which makes it a far more stable foundation for locating elements than CSS structure.

Rank selectors, accessibility-first — Every element gets candidate locators scored against an accessibility-first preference order — test-id > ARIA role > label > placeholder > text > alt-text > title > id/name attribute > raw CSS path — and ranked by a confidence score, so the most stable available locator wins. Known traps are down-ranked — a name-based locator on a text input (which carries the user's typed value) or a test-id that looks auto-generated loses confidence so it isn't relied on.

Prove assertions against the live DOM — As the agent reaches the outcome of each flow, it verifies candidate checks against the running page and only keeps the ones that actually hold — text that's really present, a value that really persisted, a URL that really changed. After the flow's main action it re-snapshots and proves a real post-condition, so a click that 'succeeded' but silently failed can't pass as green. Assertions that don't prove out are dropped, not hallucinated.

Emit native Playwright and gate dynamic checks — Output is standard @playwright/test .spec.ts committed to your repo — no DSL, no SDK, no lock-in. A quality gate classifies each assertion by stability and rejects ones pinned to ephemeral or per-run data, steering them to a durable alternative (a stable heading, a structural landmark, a regex) so the test isn't flaky by construction.

Verify with a real run, then keep it green — Each generated test is executed with native Playwright before it's trusted: pass and it's promoted to an active test, fail and it's repaired and re-run. When the UI later drifts and a selector breaks, the self-healing pass re-walks the flow against the live app, re-discovers the right locator, and rewrites the broken step — so a cosmetic change doesn't turn the suite red.

Open UI testing · Get Started Free