When Linus Torvalds released the Linux kernel in 1991, the new, open source operating system was not for the faint of heart. Unless you enjoyed writing custom device drivers, porting applications between platforms and compiling lots and lots of code, you were not poised to become a Linux user in 1991. Even skilled IT professionals who knew how to do these things struggled to justify the time they required.
This changed by the mid-1990s, however, when Linux began taking off in popularity. The reason was not because Linux grew inherently less difficult to use; the kernel actually grew more complex as it evolved. Instead, what made Linux accessible was that platforms started to grow around it in the form of Linux distributions like Red Hat and Slackware. Those platforms did the hard work of managing device drivers, compiling code and providing ready-to-install software packages.
There’s a similar story to tell about other open source platforms, such as Kubernetes or Git. In their raw, upstream forms, they’re not all that user-friendly. But the reason they’ve become massively popular is due to the emergence of platforms (like cloud-based Kubernetes services, GitHub and GitLab) that dramatically streamline the process of actually using these powerful tools.
The need for Playwright governance
The histories of Linux, Kubernetes or Git are worth mentioning in QA circles because they help predict how the landscape surrounding another increasingly popular open source tool will play out.
That tool is Playwright, the test automation framework Microsoft introduced in 2020. Playwright is a powerful tool. Features like auto-waiting and native browser-based test execution solve some of the major pain points associated with earlier testing frameworks.
But at the same time, Playwright introduces complexities that are not dissimilar to those that have made other important open source technologies difficult for many teams to fully use.
In the case of Playwright, key challenges include:
- The need to be able to code in a language like TypeScript or Javascript to write Playwright tests. Most QA professionals are not also developers, so this can be a big barrier to using Playwright.
- Lack of built-in test auditing capabilities, making it difficult to prove what you tested.
- No native test management to track tests and identify trends across your estate. This makes it hard to answer questions like, “is this test flaky just for our team, or is it part of a flake trend that affects the whole organization?”
- A lack of governance controls to align test owners and executors with organizational standards and policies.
See how Leapwork can support your entire testing suite beyond Playwright
Collectively, challenges like these make it difficult for an organization to integrate Playwright seamlessly into an effective QA strategy at enterprise scale.
Most teams also reach Playwright through a coding assistant like Claude using Playwright MCP. That speeds up writing, but it does not solve for organizational ownership. An MCP session runs on one developer’s machine, at that developer’s request, with no scheduling, no shared history, no approvals, and no one accountable when that developer changes teams. The bottom line is that you still own running, maintaining, reviewing, and proving scripts and tests.
Leapwork Play: An AI-native, governed solution for Playwright
Even if QA teams excel at writing tests for Playwright, they struggle with the orchestration, management, and governance aspects of using Playwright.
This is exactly why we built Leapwork Play. Specifically, Play provides the governance, auditing, orchestration, and test management capabilities that QA teams need to align Playwright-based testing workflows with organizational QA requirements.
With Playwright or the Playwright MCP coupled with a coding agent, your governance structure is whatever your repo process enforces. Teams also either need to build traceability and auditing capabilities or go without it.
In contrast, Play possesses role-based permissions, approval workflows, and audit logs. With Play, every step traces to a requirement, ticket, or document. Approvals, history, and run logs easily export as evidence. Every test run through a coding assistant lands in a governed suite, alleviating all governance, auditing, and traceability worries.
Just as important, Play provides built-in test authorship capabilities that allow QA professionals with minimal coding experience to write tests that don’t just run, but actually provide reliable coverage.
Play does all of this through a user-friendly graphical interface, or via MCP. The result is a user experience that feels as intuitive as a low-code solution, but that still delivers full access to the powerful capabilities that Playwright’s code-centric architecture provides.
