How it works
One pipeline: explore the app, plan coverage, generate native Playwright, verify every test against the live app, then heal it when things change.
Every test Validate.QA produces goes through the same five-stage pipeline. The goal is simple: tests that mean something, that you own, and that don't rot the first time you ship a redesign.
The pipeline
Explore — A headless Chromium agent walks your app from its URL — navigating pages, opening forms, following links — and records structured DOM snapshots, a full network HAR, and the browser console along the way.
Plan — From everything it observed, the agent groups the app into features and plans the scenarios worth covering, prioritizing real user flows over trivial page loads.
Generate — Each scenario becomes native @playwright/test code. Selectors come from a stability-ordered strategy and assertions are written from what the app actually did.
Verify — Before a test is promoted, it's run against the live app. Assertions that don't prove out are dropped, not guessed. Tests that don't pass stay as drafts instead of polluting your suite.
Heal — When the app changes and a test later breaks, the platform first decides whether it's test drift or a real app bug, then attempts an automatic repair before escalating to you.
What gets captured
Because the agent drives a real browser, a single exploration pass yields more than UI steps:
DOM snapshots for resilient, accessibility-first selectors.
A full network HAR — every request and response — which also powers API tests and the security audit.
The browser console, so silent JavaScript errors and uncaught exceptions show up in the discovery session's health report.
Visual checks
On every page a survey or discovery run visits, Validate.QA also checks the live page for cut-off or spilling text, buttons and links that are covered or cut off by the edge of the screen, an overlay that blocks the page, broken images, and low text contrast. These layout checks need no AI, and they skip patterns that sites use on purpose, such as ellipsis truncation, carousels, collapsed menus, sticky headers and cookie banners. Each page is checked at desktop size and at phone size (390 by 844), and Site Intelligence shows a Web and a Phone tab for each page.
Each finding has a cropped screenshot, a CSS selector, a position, a description and a severity. Visual issues are findings, like security findings, never test failures: you can flag one as a bug or dismiss it, and an issue that no longer shows up on a re-checked page is marked fixed. They appear in Site Intelligence, on each discovery session, in a Visual tab on each feature and in Reports, and coding agents can read them with the list_visual_issues MCP tool. An optional Gemini review of page screenshots runs once an admin saves the team's Gemini API key in Admin AI Settings, with a switch there to turn it off.
The test lifecycle
Tests move through a simple lifecycle so your suite stays trustworthy: a new test is a draft until a run proves it passes, at which point it becomes active. If an active test fails repeatedly, it's queued for healing; if it can't be healed and looks like a genuine regression, it's quarantined and flagged rather than left to flake.
Open How it works · Get Started Free