Short answer: Most people searching this already have a Playwright suite and are tired of fixing it. The tools that come up mostly write more Playwright for you, which moves the typing off your plate and leaves the maintenance where it was. QA.tech doesn't write any. You describe what a test should prove, and an agent works out the clicks on the live app every time it runs. If what you want is a different framework, Cypress and WebdriverIO are further down.
What teams are actually leaving
Playwright is winning as a framework, and we'd keep it for some things too. It's on version 1.63, runs Chromium, WebKit and Firefox, and has first-party AI in the Playwright MCP server and the planner, generator and healer agents. In State of JS 2025 it scores 94% satisfaction against Selenium's 24%.
The complaints we hear aren't about the framework. A consultant working on a consumer brand's e-commerce platform told us that now they're vibe-coding, everything just breaks, it takes too much time to update the Playwright tests and everybody gets bored by Playwright. An engineer at a media company said change the size of a button and the tests say something's broken when nothing is. A product lead at a B2B ML platform said of his four QAs only one is fluent with Playwright and developers won't write it. A QA engineer at a retail-software company put selectors and timing at 80% of all the problems in UI automation.
None of them was asking for a different framework. What they share is a suite that grew past the point where anyone has time to repair it. A QA lead at a healthcare software company said it plainly: if someone changed something in the feature and it broke our test, we have no time to fix those.
The one that doesn't produce a script: QA.tech
Instead of a .spec.ts, you write what the test should prove, and an agent works out the clicks on the live app each time it runs. It reads the rendered screen together with the page's DOM and accessibility labels. There are no CSS selectors or XPaths for you to write and none to go stale, so changing the size of a button, the media company's example, doesn't change the test. Where a journey must never vary, you write the exact labels, URLs and order into the steps as checks. The agent adapts to anything you haven't pinned, so only what you assert can fail.
There's no Playwright export because there's no Playwright underneath; definitions export as JSON or CSV. Your coding agent can drive it through the MCP server, triggering runs, reading traces and creating test cases from chat. Web runs on Chrome, so Chromium only, with configurable mobile and tablet viewport presets; a phone preset is Chrome at a phone viewport, not Safari's engine. Native iOS and Android run on cloud simulators and emulators, with real devices listed as coming soon. Billing is metered on test executions with unlimited test creation; PR testing, mobile and MCP are on the Growth plan and up.
Vilhelm von Ehrenheim, QA.tech's co-founder and Chief AI Officer, put the coverage problem this way on a September 2026 webinar: a classic regression suite would need hundreds of thousands of test cases to check every nitty-gritty detail, it would be extremely brittle as things change over time, and even then you're cherry-picking parts of the application, because there are always variations nobody anticipated.
A result on a pull request from our demo CRM: the new health badge worked on the pipeline board and the deals list, and was missing on the deal's own detail page. The eight were picked from the diff by the agent, not from a .spec.ts list, and the failure came with a screenshot rather than a selector error.
Keeping Playwright is the normal outcome, not the compromise. Daniel Mauno Pettersson, QA.tech's co-founder and CEO, says most of our clients have Playwright tests for happy-path scenarios they want to run fast and often, and that this isn't a replacement for a good unit or integration suite. What the agent covers is the long tail: the edge cases you'd test once by hand and never bother automating. The consultant at the consumer brand asked whether he should keep Playwright for his two or three money-making flows. He should. Keeping it for everything else is the part to stop.
One trade-off to know going in, because Daniel states it on calls rather than around it: the agent doesn't walk an identical path every run, and per-run cost is higher than a scripted test. His argument is that varied paths find more real bugs, and that the answer to cost is being deliberate about what runs when, not running everything every time.
The AI tools that still hand you Playwright
Almost everything sold as a Playwright alternative is a generator. You describe a flow, it writes Playwright into your repo, and from then on the suite is yours. What's automated is the typing. The artefact is the same one you have now, and so is the job of keeping it green, which is why every tool in this group ships a repair feature.
Playwright does this itself, free and first-party. Since 1.56, npx playwright init-agents sets up a planner, a generator and a healer. If a generated Playwright suite is what you want, start there rather than paying a vendor for the same output. The healer exists because the tests break.
An e-learning company told us they run 14 to 16 AI agents in their pipeline, some generating Playwright for each feature, and the questions they brought us were still price, maintenance burden, flaky tests and false positives. Generating the scripts cheaply doesn't change what happens next. Every product change is a change to the scripts, and somebody has to trust that change too. Runtime piles up on its own: in the suites we've seen, a hundred Playwright tests run in a minute or two and a few thousand take half an hour or more.
An engineering lead at a workforce-management software company put the economics of this better than we do. Flaky tests, he said, are just speed delays in disguise, and if it isn't a 10x speed difference he wants quality more than anything else.
Three frameworks, if the framework is the problem
Cypress. In-browser, time-travel debugging, Cloud at $67 a month for Team, billed annually. JavaScript only, one browser at a time and one superdomain per test unless you use cy.origin, per its own trade-offs page. We wrote a neutral Playwright vs Cypress comparison.
WebdriverIO. Node over WebDriver, BiDi and Appium, so web and real mobile devices share one API. You run the driver, which is the thing Playwright let you stop doing.
Selenium. 4.50, released 30 September 2026, still on WebDriver Classic for most users while BiDi lands, no runner, no auto-wait, and no first-party agent tooling. We rarely hear of anyone moving this direction; see Selenium alternatives for the other way.
Quick comparison
| Tool | Cost (6 Oct 2026) | What you end up owning | Breaks on UI change? |
|---|---|---|---|
| Playwright | Free | Playwright suite | Yes |
| Cypress | Free; Cloud from $67/mo | Cypress suite | Yes |
| WebdriverIO | Free | WebdriverIO suite + driver | Yes |
| Selenium | Free | Selenium suite + runner you build | Yes |
| Playwright test agents | Free | Playwright suite, generated | Yes, healer repairs after |
| AI test generators | Varies | Playwright suite, generated | Yes, each ships a repair feature |
| QA.tech | Metered on test executions | Plain-language goals, no suite file | No, the goal hasn't changed |
Also in this series: BrowserStack alternatives, Selenium alternatives and TestSprite alternatives.