Environments
Point the same suite at local, UAT, staging or production. URLs and credentials live in the environment, never in the test.
Click through your app and QAright builds the test. When your screens change, it repairs itself.
| # | Action | Locator / value | |
|---|---|---|---|
| 03 | Fill | ● GetByRole(AriaRole.Textbox, new() { Name = "Password" }) | 0.3s |
| 04 | Click | ● GetByRole(AriaRole.Button, new() { Name = "New claim" }) | HEALED1.2s |
|
Primary
GetByTestId("new-claim")not foundHealed to
GetByRole(AriaRole.Button, "New claim")fallback 2 of 6 · score 91 |
|||
| 05 | Assert | ● GetByRole(AriaRole.Heading, new() { Name = "New claim" }) | 0.4s |
| 06 | Fill | ● GetByLabel("Claim type") | 0.2s |
| Blocking | Payment — saved card
data-testid="pay-now" removed from /checkout |
| Minor | Submit new claim
"Continue" renamed to "Next step" |
| Clean | Customer login
no change since 12 Aug |
It fails on a Tuesday, someone adds a retry, and six weeks later the pipeline is a formality nobody reads. Three things get you there.
Most tools record a single selector. When the DOM shifts, there is nothing to fall back to, so a cosmetic change reads as a product failure.
A stack trace tells you an element wasn't found. It doesn't tell you the id went dynamic, or that a cookie banner is sitting on top of the button.
Drift is discovered when the suite goes red at 2am — after the deploy, in front of everyone, at the least convenient possible moment.
Click through your app in a real browser. QAright captures the intent behind each action, not just the coordinates.
| # | Action | Locator / value |
|---|---|---|
| 01 | Navigate | https://app.everline.example/login |
| 02 | Fill | ● Locator("#login-form").GetByRole(AriaRole.Textbox, new() { Name = "Email", Exact = true }) |
| 03 | Fill | ● Locator("#login-form").GetByRole(AriaRole.Textbox, new() { Name = "Password", Exact = true }) |
| 04 | Click | ● Locator("#login-form").GetByRole(AriaRole.Button, new() { Name = "Sign in", Exact = true }) |
| 05 | Assert | ● GetByRole(AriaRole.Heading, new() { Name = "Your policies" }) |
| 06 | Click | ● GetByTestId("new-claim") |
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.
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.
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.
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.
Most flaky automation comes from a tool guessing confidently. The cascade is deliberately conservative.
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.
You get told a test id disappeared on the payment page on Tuesday morning, not when the nightly run goes red on Friday.
Drift is reported against the page that changed, so one navigation rewrite shows up once rather than as thirty separate failures.
Guardian replays a recorded login segment to reach authenticated pages, so coverage doesn't stop at the sign-in screen.
Recording is the easy part. Everything below is what makes a suite survive contact with more than one engineer.
Point the same suite at local, UAT, staging or production. URLs and credentials live in the environment, never in the test.
Named datasets plus generated values. {{env.KEY}}, {{data.key}}, {{faker.EMAIL}} and {{capture.VAR}} resolve at run time.
Tag cases and run subsets. smoke,regression to include, ~slow to exclude.
Compressed screenshots per run, full-page on failure, with baselines for comparison and a lightbox on every step.
Pass-rate trend, slowest steps, flaky and consistently broken cases, and per-run performance metrics.
Mix HTTP calls into a browser scenario — seed a record, capture a value from the response, then assert on it in the UI.
POST to /api/trigger with an API key from GitHub Actions, Azure DevOps, GitLab or Jenkins. Block on the result or poll it.
Organisations, projects, role-based access, version history on every case and an audit log of who changed what.
Click any element in a live page to see its candidate locators, their scores, and whether each one is actually unique.
Healing runs locally. That is an architectural choice, not a pricing tier — and it has consequences worth knowing about.
Repairs are computed from candidates and snapshots you already hold. Your DOM is not sent to a third party to be analysed.
No outbound call is required for a run to succeed, so QAright works on isolated networks and behind strict egress rules.
The AI healing phase is off unless you enable it, and it calls the model endpoint you configure — under your key, your region, your retention.
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.
Anyone who wants to see whether this works on their app.
No card. One seat.
Get early accessOne engineer keeping a suite alive alongside everything else.
Billed monthly. One seat.
Get early accessA QA team sharing suites across environments and a pipeline.
Billed monthly. Minimum 3 seats.
Get early accessRegulated environments, private networks, and procurement.
Annual agreement.
Talk to usEarly access — pricing is not final and may change at general availability. Every plan runs on your own infrastructure, and your tests export to plain C# whenever you want to leave.
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.
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.
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.
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.
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.
Chromium, Firefox and WebKit, headed or headless, and a suite can be run across several of them in parallel in a single execution.
QAright is in early access. If you have a suite that people have quietly stopped trusting, that is exactly the one we want to see.