Playwright specs that survive a redesign
Record once. Never test that flow by hand again.
Click through checkout the way a user would. QAZero stores a fingerprint for every element — not a CSS class — and emits a Playwright spec. When a developer renames a button, the spec re-binds. When you need proof it catches the bug, the RED gate runs it against the broken build first.
Built by the QA engineer behind test automation at Polymarket, upcover, Kinnect, and Brahma.
The problem
Your tests break more than your code does.
A developer renames a class and six specs go red. Someone spends the afternoon chasing selectors. None of that work caught a bug.
The flows that make money — checkout, onboarding, billing — are still clicked through by hand, because writing those specs is a week nobody has.
- 01
Stale locators
Selectors go stale the sprint after you record them.
- 02
Called flaky
“Flaky” is often a locator that pointed at yesterday’s DOM.
- 03
Checkout
Checkout still has no spec because the last one rotted.
How it works
Three steps. You only do the first one.
- 01
Record
Add a script tag to staging, or load the Chrome extension. Click through the flow. Every step is a fingerprint (role, name, test id, structure, geometry) — not div.btn-primary.
- 02
Spec
QAZero emits a Playwright file plus a sidecar of ranked locators. You can download it. It is ordinary spec.ts. Nothing proprietary.
- 03
Gate, then CI
The RED gate runs the spec against a build where the bug still exists. Fail then pass is the proof. After that, the GitHub Action runs it on every PR. When the UI moves, healing re-binds the locator instead of going red.
Healing
The UI changed. The test continued.
Most heals never call a model. Cached locator, then a recorded alternate, then fingerprint similarity. Claude is last, and only if those miss.
- 01Free
Cached locator
Last run still matches. Fast. Most steps stop here.
- 02Free
Recorded alternate
Another locator from the original fingerprint matches uniquely.
- 03Free
Fingerprint re-match
Similarity against the live DOM — role, name, structure, geometry.
- 04Paid
Claude
Screenshot + DOM, only if the rest failed. The dashboard shows the cost.
Locator rank
- test id
- role + accessible name
- label
- placeholder
- alt / title / text
- role alone
- CSS (hashed classes rejected)
- XPath last
Ambiguity wins: a test id on five buttons loses to role+name on one.
Who it’s for
Built for teams that would rather ship than babysit a pipeline.
Startup CTOs
No dedicated QA. Record checkout once.
Engineering managers
Stop paying sprints to rewrite selectors.
QA leads
Automate the regression loop. Keep exploratory for yourself.
Why QAZero exists
I’ve built this system four times. This is the fifth — done right.
At four different startups — a DeFi prediction market, an insurtech, and two fast-moving product teams — I was the QA engineer. And at every single one, I ended up building the same thing from scratch: automated end-to-end tests, CI integration, and endless selector maintenance to keep them green.
Every company had the same problem. Every company needed the same solution. Nobody could buy it — so someone like me had to build it, badly, in the gaps between sprints.
QAZero is that system, productized: fingerprints instead of selectors, a RED gate so a spec has to prove it would have caught the bug, and healing that does not start with an LLM.
— Saswat Marpureddy, Founder
Pricing
Start with one flow, not a 20-person QA team.
Pilots. Billing is not self-serve yet. Open the app, or book a walkthrough of one recorded flow.
Starter
Talk to us
One staging app. Snippet or extension. Hosted runs. RED gate. GitHub Action on Chromium. Dashboard.
- Record with the snippet or Chrome extension
- Download ordinary Playwright specs
- RED gate against the unfixed build
- Hosted runs on Browserbase
- GitHub Action on Chromium
Growth
Talk to us
More flows, signed-in recording, CI on every PR, walkthroughs.
- Everything in Starter
- Signed-in recording
- CI on every pull request
- Walkthroughs with the founder
Comparison
You keep the specs. Healing is not a human sitting on the suite.
Not an AI QA agency. Not a hosted test cloud. A fingerprint, a RED gate, and ordinary Playwright files.
| Capability | QAZero | Doing it yourself | QA Wolf |
|---|---|---|---|
| You record | Yes — snippet or extension | You write every spec | They staff writers |
| What you keep | Playwright in your repo | Your repo | Their cloud |
| Healing | Four tiers; AI last | Manual rewrites | Human maintainers |
| Proof it catches the bug | RED gate | Hope | Their process |
| Lock-in | Specs are yours | None | High |
Walkthrough
Book a walkthrough
One recorded flow, on a call. Not a 48-hour AI audit of accessibility or performance. Pick a time, or email.
FAQ
Questions engineers actually ask.
What if the UI changes every sprint?
Healing tries the cached locator, then a recorded alternate, then fingerprint similarity. Claude only if those miss. The spec stays a Playwright file.
Who is behind this?
Saswat Marpureddy. Test automation at Polymarket, upcover, Kinnect, and Brahma. Same problem at every one: checkout tested by hand, selectors rotting.
Do we own the tests?
Yes. Download spec.ts. Run it with Playwright. The GitHub Action is this repo, not a black box.
How do we start?
Create a workspace at https://app.qazerolabs.com/sign-up, paste the snippet on staging, record one flow.
Is this Jam / English-to-test?
No. You click through the real UI. That is how the fingerprint exists.
Firefox / Safari / mobile?
Chromium today. Hosted runs use Browserbase. CI uses GitHub Actions.
Visual regression, a11y, performance?
Not this product. The job is a durable spec for a flow you already care about.