Playwright’s rise as a web automation tool for testing has been remarkable: adoption rates soared from 1 million weekly npm downloads in 2021 to 83 million weekly npm downloads in Q3 2026, the latest reports show. The growth in 2026 alone has been immense: In Q1 2026, Playwright had 33 million weekly npm downloads, according to Tech Insider.
The most interesting question surrounding Playwright’s spike in popularity is why the adoption curve went practically vertical this past year. The answer says a lot about where testing is headed next.
Browser automation has always tracked release cadence. When releases happened every few months, a QA team could click through an application for two weeks, and that was fine. Agile compressed that cadence, and Selenium made automated browser testing practical. Then CI/CD moved teams to per-commit deployments, JavaScript frameworks turned websites into applications running inside the browser, and the browser itself became something closer to an operating system.
Why Playwright feels different
Playwright was designed for this sort of environment rather than being retrofitted into it: –
- Automatic waiting removed the synchronization spaghetti code that teams maintained by hand.
- Browser contexts isolate test state, so the test that adds something to a cart doesn’t corrupt the test that checks out.
- Network interception reproduces an API failure in a few lines instead of an environment.
- When something breaks, traces, video and network logs mean you’re watching the failure rather than playing Sherlock Holmes with a stack trace.
Selenium solved a foundational problem: How do I control a browser? Playwright turned the focus towards the practitioner and asked something closer to: How do I help a developer ship with confidence? That distinction is important.
AI removed Playwright’s biggest adoption barrier
Despite its technical advantages, Playwright still required code, which was never a problem for SDETs and engineers. But a lot of QA professionals who understand application behavior and business risk better than anyone weren’t going to build and maintain a large TypeScript framework.
AI coding tools are removing that barrier fast, and that opens Playwright to a much wider group of people. It also introduces a contradiction: AI is probabilistic, but testing needs to be deterministic. Those two are at odds, and the conflict gets exponentially worse the more tests you generate.
A green test is not necessarily a safe test
We ran into this issue ourselves at Leapwork. Before building Leapwork Play, the newest component of our Continuous Validation Platform, our team was running Playwright with AI using roughly the approach the rest of the market is starting to adopt. The metrics looked great: near-total coverage, everything passing.
Then we started peeling back the onion to see what those tests were actually validating, as the software we were testing wasn’t functioning as intended despite the passing tests. Some of the AI-generated tests had intentionally been written to pass. The code would manipulate the application, reach the end of the flow and return green without validating what the business actually cared about. This isn’t an issue you’d find unless you went looking for it.
Green tells you a test executed successfully. Safe tells you the organization can trust what that result means. Playwright’s own documentation is honest about this: its agent-generated tests need human review. But when AI is producing hundreds of tests in a few days, nobody is reviewing all of them.What you’re left with is volume without verification.
Playwright scales the developer, but enterprises need to scale confidence
A developer wants to know whether their change broke the application, whereas the enterprise wants to know whether it can safely ship on Thursday. Large organizations run web applications alongside APIs, SAP, Salesforce, Citrix-published desktop apps, mainframe systems and third-party SaaS. A Playwright test can validate one component of that estate perfectly while the end-to-end business process still fails.
Enterprises also need to prove it afterward: what was tested, why, what the expected outcome was, who changed the test, and whether any of it survives an audit. That’s the gap between automation and continuous validation. It’s a question of scope, since Playwright never claimed to test a mainframe.
You don’t need to give up Playwright to fix the gap
This is what Leapwork Play is built for, and the goal isn’t to replace Playwright. Playwright is an excellent browser automation framework and teams should keep using it.
Play adds what you need once Playwright becomes an enterprise testing strategy. That looks like this:
- AI authors the tests, but the resulting code runs deterministically, so there’s no token cost and no model dependency at runtime.
- Tests link to evidence and reporting.
- Audit logging, security and access controls handle governance.
- Reusable components let teams share automation instead of rebuilding the same tests across applications.
- Through MCP, Play sits alongside AI coding workflows so validation happens while software is being generated rather than as a separate step afterward.
Playwright sped up browser automation . AI is accelerating test creation even faster. The only remaining problem is ensuring all of it is trustworthy at enterprise scale. Because when delivery is continuous, validation needs to be as well.
The wider Leapwork Continuous Validation Platform extends this functionality past the browser, bringing Play together with Flow and Go to cover more of the estate.
