Playwright test automation, without writing the Playwright

QAright is built on Microsoft Playwright. You record a test by clicking through your app; it plays back on Playwright in Chromium, Firefox or WebKit, repairs locators that stop matching, and exports to a normal C# Playwright project whenever you want the code. This page is about what that layer adds, and where writing Playwright directly is still the better choice.

What Playwright already does well

Playwright is the reason browser tests stopped being a byword for flakiness. It waits for an element to be actionable before acting on it, drives three browser engines through one API, isolates each test in its own browser context, and records a trace a person can step through after a failure. None of that is replaced here. Every run in QAright is a Playwright run, with the same auto-waiting and the same engines.

What a suite still needs on top of it

What Playwright leaves to you is the part that costs the most over a year: choosing a locator that survives the next redesign, noticing when one no longer does, and knowing which failures are the application and which are the test. That is the layer QAright adds.

1. Several locators per step, ranked.

   Recording stores a set of candidate locators for every element — role and name, test id, label, text, a scoped CSS path — scored for how likely each is to survive a change, and checked for how many elements each matches at the moment it was captured. Playwright’s own codegen writes one.

2. Repair at run time, written down.

   When the first locator stops matching, the run works down the others in order, and then compares the recorded element with what is on the page now. Every repair is in the report, and a fallback only becomes the primary after it has won several runs in a row. Self-healing test automation walks through the order and what it refuses to do.

3. Waits that were measured.

   A click that navigates records how long the page actually took to settle, and the wait is built from that measurement rather than a guessed timeout. A run that is slow for a real reason gets more time; one where nothing is happening fails as fast as before. Flaky tests explains the difference.

4. Drift found before a run.

   Guardian compares your live pages with what was recorded and reports what moved while the suite is still green. See test drift detection.

5. The rest of the suite.

   Environments and data profiles instead of hard-coded URLs and passwords, scheduled runs, CI/CD triggers, parallel runs across browsers, reports with screenshots, and an AI assistant that can work on the suite over MCP.

You still own the code

Every suite exports to a self-contained C# Playwright project: the tests, the same resilient execution engine the app runs, the data generators and a project file. It compiles and runs with dotnet test, with or without QAright, and the recorded fallbacks travel with it. Export is on the free plan and is not rate limited. The bundle carries no credentials: an exported test reads its secrets from the machine’s own environment variables.

When to write Playwright yourself instead

• Your team writes TypeScript tests in the application repository.The export is C#. If the tests have to live beside the code in the same language, write them there.
• The test is mostly logic, not clicks.Heavy branching, generated test matrices or deep use of the Playwright API are easier to express as code, even though steps here can call APIs, loop and run conditionally.
• You need a browser QAright does not record in.Recording runs in Chrome or Edge today; playback covers Chromium, Firefox and WebKit.

For everyone else — testers who do not want to maintain a codebase, and developers who are tired of fixing selectors after every release — recording on top of Playwright keeps the parts of Playwright that work and takes away most of the upkeep.

Keep reading. Playwright’s own documentation, in the order worth reading it, is Playwright documentation, in reading order. How it works follows one recording to its report, and AI test automation over MCP covers the assistant.