Automated testing without the code, or the maintenance.
Record and playback for browser tests, built on Playwright, with no code to write. Click through your app and QAright builds the test. When your screens change, it repairs itself.
Maintenance is the part you stop doing.
Record a test — or ask AI to draft it. After that QAright runs it, diagnoses what failed, and proves every repair before offering it to you.
Runs on a schedule or on every deploy, and watches your recorded pages for drift in between.
Diagnoses the failure in plain English and proposes a repair it has already proved by running the step.
Nothing lands on the model’s word alone. Every automatic change is versioned, audited and yours to undo.
Create once
-
Create the testYouAI
Record by clicking through your app, or generate one from a description.
Continuous lifecycle
-
Run on every deployAutomatic
Runs on a schedule, on a push from CI, or on demand.
-
Classify failuresAutomatic
Timing, locator, or the application itself — decided from the evidence.
-
Explain root causeAI
The cause in plain English: the id went dynamic, a banner covered the button.
-
Propose a repairAI
A new locator, found on the live page and scored against the recorded element.
-
Verify with a rerunAutomatic
The step runs with the fix, and so does the step after it.
-
Review and write backYou
A repair is applied when you click. Anything automatic is versioned, audited, undoable.
-
Monitor for driftAutomatic
Between runs your recorded pages are re-walked, and what moved is reported.
Free forever, and no card.
Record once. Keep it running.
Click through your app in a real browser. QAright captures the intent behind each action, not just the coordinates.
Every element, described several ways
At record time each element is described by up to fourteen candidate locators — test ids, ARIA role and name, label association, scoped CSS paths — and each one is 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.
Watch it execute, and step in mid-run
Runs stream live over the wire. Pause between steps, inspect the variables the scenario has captured so far, edit a step that is about to run, and resume — without restarting the scenario.
- Pause, resume and cancel at clean step boundaries — never mid-action.
- Per-step retries, timeouts and wait strategies, configurable per step.
- A step can be conditional on a captured value, and a group of steps can repeat a fixed number of times or until a condition stops holding. A step that is skipped says why, and does not count as a pass.
- Full-page screenshots on failure, with an optional per-step timeline.
- Run in parallel across Chromium, Firefox and WebKit.
Leave whenever you like
Every suite exports to a self-contained C# Playwright project — the test, the resilient execution engine, the data generators and a project file. It compiles and runs with dotnet test, with or without QAright.
- Readable page objects generated from your recorded app model.
- The same healing logic ships inside the export, so exported tests keep their fallbacks.
- No proprietary run format and no lock-in — it is a normal .NET project.
An ordered chain, not a guess
When the primary locator misses, QAright works down a defined cascade. Each phase is logged, so a repair is always something you can read back and disagree with.
- 1Primary locatorHighest-scoring candidate from record time
- 2Fallback candidatesThe rest in rank order, each probed for uniqueness
- 3App model lookupMatched against the crawled model of your app
- 4Semantic scanLive elements scored against the recorded snapshot
- 5AI-assisted repairOptional, and only through a model you configure
Stops at the first phase that finds one unique match. Every phase tried is logged.
Healing that refuses to be clever
Most flaky automation comes from a tool guessing confidently. The cascade is deliberately conservative. There is a longer piece on how the self-healing works, and one on what actually makes a test flaky.
- Never heal an assertion. A broken path to an element is recoverable. An element found in the wrong state is a real failure and is reported as one.
- Never resolve ambiguity by guessing. If a candidate matches several elements and scores poorly, it is refused rather than picked.
- Never invent a candidate. Healing re-ranks what capture recorded; it does not fabricate selectors from a stale DOM.
- Never silently rewrite 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.
That whole loop runs free, with no cap on how many tests.
Find the drift before the suite does
Guardian walks your recorded pages on a schedule — or on every deploy — and compares what it finds against the DOM snapshots captured when you recorded. It reports what moved while the suite is still green, and rolls each change up to a risk level per test, so you can tell a cosmetic rename from one that will block the run.
How drift detection works explains what is compared and when.
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 doesn't stop at the sign-in screen.
The rest of what a real suite needs
Recording is the easy part. Everything below is what makes a suite survive contact with more than one engineer. If you would rather read it in order, how it works walks the whole loop from recording to report, and record and playback testing covers where the approach earns its keep and where it does not.
Environments
Point the same suite at local, UAT, staging or production. URLs and credentials live in the environment, never in the test.
Data profiles & tables
Named datasets, generated values, or a table of rows that runs the case once per row. {{env.KEY}}, {{data.key}}, {{faker.EMAIL}} and {{capture.VAR}} resolve at run time.
API steps
Mix HTTP calls into a browser scenario — seed a record, capture a value from the response, then assert on it in the UI.
CI/CD triggers
One authenticated endpoint any pipeline can call. POST to /api/trigger with an API key, filter to the tags you want — smoke on every commit, the whole suite nightly — and block on the result. No plugin, nothing provider-specific.
Teams & roles
Organisations, projects, role-based access, version history on every case and an audit log of who changed what.
Analytics
Pass-rate trend, slowest steps, flaky and consistently broken cases, and per-run performance metrics.
Your assistant can maintain the suite too
Connect Claude Code, Cursor, VS Code or Claude Desktop over MCP. Ask why last night’s run failed and it reads the run history, checks a replacement locator against the live page and applies the fix. Hand it a user story and it writes the test. It works as you, with a tester’s permissions, and every change it makes is in the test’s history under your name.
Available on Solo and above. Create a key in Settings, copy the setup for your assistant, and it is connected. What the assistant can and cannot do.
It can
- Read run history, reports and what is flaky
- Run a test or a suite, and rerun one to see if a fix holds
- Check a locator on the live page before anything is saved
- Create and update tests, steps, waits and timeouts
It cannot
- Delete a suite or a test — there is no such tool
- Manage users, API keys or billing, whoever owns the key
- Use a locator somebody rejected, or shorten a step’s timeout
- See a secret value, or record
It uses none of your plan’s AI allowance: the reasoning is your assistant’s, and QAright runs the tests and answers its questions. Each key is shown once, belongs to one assistant, and is revoked in one click.
Your browsers, your network, your data
Healing runs locally. That is an architectural choice, not a pricing tier — and it has consequences worth knowing about.
Nothing is shipped out to heal
Repairs are computed from candidates and snapshots you already hold. Your DOM is not sent to a third party to be analysed.
Works air-gapped
No outbound call is required for a run to succeed, so QAright works on isolated networks and behind strict egress rules.
AI is the last resort, and it never sees your page
The heal chain tries your own locator, its fallbacks, the app model and a DOM snapshot you already hold. Only when all of those fail does a model see anything — and what it sees is the locator, the action and the error text. Never the page. On qaright.com that call runs against our model; self-hosted, it runs against yours.
A password is a secret from the moment it is typed
A recorded password is masked at capture, not on the way out — so it is already hidden in the case, the run report, the CSV, the export and the prompt sent to a model. Mark any environment variable, data key or table column secret and the same applies to it.
Priced per person, not per test run
Run as often as you like. You are never charged for executing a test, so nobody has to ration the suite to stay in budget.
Free
One person testing their own app, on their own machines.
No card. One seat.
Get started free- Unlimited tests, suites and runs
- Ranked locator candidates, scored for stability
- Self-healing cascade and healing report
- Element inspector and assertion builder
- Reports, screenshots and analytics, with PDF/CSV export
- Unlimited export to a standalone C# Playwright project
- Two environments and two data profiles
- Five of each AI feature a month
- 30 days of run history
Solo
One engineer keeping a suite alive alongside everything else.
Billed monthly. One seat. Start free — we set the paid plan up with you.
Get started free- Everything in Free, plus
- Guardian drift detection, on up to 5 URLs
- Scheduled runs, CI/CD triggers and API keys
- Your AI assistant (Claude Code, Cursor, VS Code) connected over MCP
- Parallel runs across two browsers at once
- Unlimited environments and data profiles
- Up to 3 projects
- 100 AI generations a month, and 50 of everything else
- 90 days of run history
Team
A QA team sharing suites across environments and a pipeline.
3 to 10 seats. Start free and we will price it with you.
Talk to us- Everything in Solo, plus
- Up to 10 seats, with roles and user management
- Guardian on every URL you record
- Parallel cross-browser runs, up to 4 at once
- Unlimited projects, and webhook notifications
- Version history and audit log
- Test executions: named test cycles, assigned per tester, manual and automated together
- Spec-driven testing, and page divergence diagnosis on failed runs
- 500 AI generations a month, and 250 of everything else
- A year of run history
The free plan is real and stays free. Paid pricing is not final during early access and may change at general availability — if you join now on a paid plan, we will tell you before anything moves. Every plan runs on your own infrastructure, and your tests export to plain C# whenever you want to leave.
The things people ask first
Do I need to know how to code?
No. Recording, editing and running a suite is entirely visual, and each step can be read as a plain-English description. If you do write code, every suite exports to a normal C# Playwright project you can own outright.
Where does the recording actually happen?
In your browser, on your machine. Recording drives a real browser you click through, so it runs where you are rather than in our datacentre — which is also why it reaches an app on localhost or an internal network that nothing hosted could see. You add the QAright recorder to Chrome or Edge once; the workspace, the suites and every run live in the app as normal. Firefox and Safari recording are not built yet.
How is this different from recording with Playwright directly?
Playwright's own codegen records one selector per action. That is fine until the DOM moves. QAright stores a ranked set of candidates, scores them for stability, repairs at run time, and keeps a history of what it repaired.
QAright is built on Microsoft Playwright and runs real Playwright underneath — the difference is what happens after the recording. Playwright, without the code goes through it, including when writing Playwright yourself is the better choice.
Doesn't self-healing just hide real bugs?
It would, if it healed assertions — so it doesn't. The cascade only repairs the path to an element. If the element is found and its state is wrong, that propagates as a failure immediately.
Every repair is also logged and surfaced in the run report, so a test that only passes because it was healed is visible rather than silently green.
What happens to my tests if we stop paying?
You export them. Suites become a self-contained .NET project that compiles and runs with dotnet test, including the resilient execution engine and your recorded fallbacks. There is no proprietary run format holding your work hostage. Export is on the free plan too, and it is not rate limited.
One thing to know before you rely on it: the bundle deliberately carries no credentials. An exported test reads {{env.KEY}} from the machine's own environment variables, and a workspace data profile does not travel with it — so a suite driven by named datasets needs those supplied on the other side. Suites also export and import as JSON between workspaces, which is the route to take if you are moving rather than leaving.
Can it test an app behind a login?
Yes. Authentication is recorded once as a reusable preamble and replayed to establish a session, which the suite and Guardian both reuse. Credentials live in an environment, not in the test.
Which browsers are supported?
Chromium, Firefox and WebKit, headed or headless, and a suite can be run across several of them in parallel in a single execution.
Bring us your flakiest suite.
Create a free workspace and record your first test in about the time it would take to write one. If you have a suite people have quietly stopped trusting, that is exactly the one we want to see.
Free forever, and no card. Already have an account? Sign in.