How QAright records, heals and reports on Playwright tests

Click through your app in a real browser. QAright captures the intent behind each action, not just the coordinates. Four things happen to a test, in order: it is recorded, it repairs itself when the page moves, it hears about drift before then, and it reports in a way someone will read.

Record by using the app

Open your application in a real browser and use it. Your clicks become steps in plain English, readable by anyone on the team — "Sign in as a policyholder", "Start a new claim" — and the same list can be flipped to a detailed view showing the resolved Playwright locator behind every step, with the fallbacks standing behind it. Nobody has to write code.

What makes the recording worth keeping is what is captured underneath each click:

• Up to fourteen candidate locators per element — test ids, ARIA role and name, label association, scoped CSS paths — each scored for how likely it is to survive the next deploy.
• Dynamic ids, UUIDs and framework-generated classes are detected and pushed down the ranking, never used as the primary.
• Candidates are checked for uniqueness as they are captured, so an ambiguous selector is flagged before it ever runs.
• Shadow DOM, slotted content and same-origin iframes are pierced to a concrete element rather than stopping at the host node.
• A DOM snapshot is stored per step — the raw material every later repair is checked against.

Anything that should not be baked into a test is not. URLs and credentials live in an environment; named datasets live in a data profile; and {{env.KEY}}, {{data.key}}, {{faker.EMAIL}} and {{capture.VAR}} resolve at run time, so the same suite runs against local, UAT, staging or production.

Why most record-and-playback tools rot, and what this one does differently: Record and playback, done properly.

Repaired at run time

Runs stream live. You can pause between steps, inspect the variables captured so far, edit a step that is about to run, and resume without restarting. Runs go across Chromium, Firefox and WebKit, headed or headless, and in parallel.

When a step's primary locator misses, the run does not stop and it does not guess. It works down a fixed cascade and reports which phase found the element: the primary locator, then the remaining fallback candidates in rank order (each probed for presence and uniqueness), then a lookup against the crawled model of your application, then a semantic scan of the live page against the recorded snapshot, and last — only if you have enabled it — an AI-assisted repair through a model you configure.

The cascade is deliberately conservative. It never heals an assertion: a broken path to an element is recoverable, but an element found in the wrong state is a real failure and is reported as one. It never resolves ambiguity by guessing, never invents a candidate that capture did not record, and never silently rewrites your test — a fallback is promoted to primary only after it has worked three runs running, and the promotion is written to the audit log.

The full chain, and the four things it refuses to do: How self-healing test automation actually works.

Drift, before the suite goes red

Healing catches a change at the moment a test hits it. Guardian catches it earlier. On a schedule, or on every deploy, it re-walks your recorded pages and compares what it finds against the DOM snapshots captured when you recorded, then rolls what moved up to a risk level per test — blocking, minor, or clean — so you can tell a cosmetic change from one that will fail the suite on its next run.

• Proactive, not reactive. You get told a test id disappeared on the payment page on Tuesday morning, not when the nightly run goes red on Friday.
• Scoped by page, not by test. Drift is reported against the page that changed, so one navigation rewrite shows up once rather than as thirty separate failures.
• Gets past your login. Guardian replays a recorded login segment to reach authenticated pages, so coverage does not stop at the sign-in screen.

What a scan actually compares, and what it deliberately ignores: What test drift detection actually catches.

The whole picture

Every result explains itself. A failure comes with the cause in plain English — the id went dynamic, a cookie banner was covering the button — and a full-page screenshot of the moment it happened, with an optional per-step timeline. Any repair the engine made is written down where you can read it back and disagree with it, so a test that only passes because it was healed is visible rather than silently green.

Analytics sit on top: pass rate, execution volume and duration over any window, the pass/fail trend, the slowest steps, the cases that are flaky and the ones that are consistently broken, with PDF and CSV export. When a step fails on time rather than on a locator, the report says which it was — a page that was slow to arrive, or an element that was never coming — because those need different fixes.

Telling a slow app from a broken one, and why retries hide the difference: Flaky tests.

And then, in your pipeline

Schedule the suite, or trigger it from GitHub Actions, Azure DevOps, GitLab or Jenkins with a single POST and an API key, and either block on the result or poll for it. Tag cases and run a subset — smoke,regression to include, ~slow to exclude. And leave whenever you like: every suite exports to a self-contained C# Playwright project that compiles and runs with dotnet test, with the same healing logic and your recorded fallbacks inside it.