For years, Selenium has been the go-to tool for automated browser testing, and for good reasons: it’s open source and free, has a large and active community, supports multiple browsers, platforms, and programming languages, and—perhaps most importantly—it’s familiar.
However, Selenium is not without its drawbacks. It tends to have slower execution compared to headless browser automation tools, lacks built-in reporting and test management features, and comes with a steep learning curve—especially for team members outside of the QA team, like engineers. And this last point matters—a lot. Here’s why.
Beyond the Testing Team: Cypress and Playwright in Modern Workflows
I had an interesting discussion at work today about The State of Front End Development, a report by The House of Software. We talked about automation tools—Cypress, Playwright, and Selenium—and their roles in modern testing workflows.
When a colleague mentioned Cypress ranked second and Playwright fifth in the report, I was intrigued. Selenium? Nowhere in the top 10.
Initially, I was surprised these tools ranked so highly. Despite competition, Selenium is still widely used in testing. But after examining the data, it made sense. The survey, which included 6,000 developers—not testers—focused on tools used by front-end developers for testing tasks like unit and integration testing. Jest, a JavaScript and TypeScript framework, unsurprisingly topped the list.
Cypress and Playwright’s prominence was even more intriguing under the context of the report, as I’d always viewed them as tools primarily aimed at testers and QA professionals – not engineers. However, their high rankings also confirmed what I’ve observed firsthand: their developer-friendly design makes them better suited to modern teams and workflows than traditional tools like Selenium.
Why Engineers Prefer Working with Cypress and Playwright1
Testing can feel like an uphill battle for developers, especially with tools that require steep learning curves or outdated workflows. Here’s why Cypress and Playwright are changing the game:
Developer-Friendly Design: Streamlined setup and configuration minimize adoption hurdles, making these tools far more accessible than Selenium.
Seamless Integration: Built to integrate effortlessly with CI/CD pipelines, ensuring testing aligns smoothly with modern delivery workflows.
Intuitive and Approachable: Clearer documentation simplify the learning curve, enabling quicker adoption and effective use.
A Real-World Case Study: Testing as a Team Sport
In past roles, I’ve seen firsthand how tools like Playwright can transform team dynamics. For example, during one project, we faced a classic challenge: too many engineers, not enough testers. To address this, we shifted test maintenance to the entire team. Another step towards making quality everyone’s responsibility.
Here’s what worked:
Empowering Engineers: When an E2E test failed after a merge, engineers took the lead in investigating the issue. Was it a genuine bug or just a test update requirement? They analysed and resolved it, with testers providing support as needed rather than immediately stepping in to fix it. Testers focused on creating new tests during sprints, but test maintenance became a shared responsibility across the team.
Lowering the Learning Curve: Playwright simplified onboarding for engineers by reducing friction. Its seamless integration with modern CI/CD pipelines and built-in features—such as tracing, screenshots, and debugging tools—eliminated the need for external libraries or frameworks like TestNG or Allure. This reduced complexity ensured engineers could get started quickly without feeling overwhelmed.
Collaborative Test Maintenance: While testers handled test creation during the sprint, maintaining those tests became a team-wide effort, fostering a culture of shared responsibility and collaboration.
Would we have had the same success with Selenium? Possibly—if it could have been implemented the same way. I’ve attempted to approach testing this way with teams using Selenium before, and it hasn’t been successful, even once. The steep learning curve alone often created resistance, undermining efforts to distribute responsibility across the team. This challenge has largely relegated Selenium to being a tool used primarily by testers.
In contrast, tools like Playwright have enabled collaboration and made it feasible to sustain a team-wide approach to testing. Their simplicity and developer-friendly design have bridged the gap, helping make testing a shared responsibility rather than a siloed activity.
Sometimes, it’s not about choosing the “best” tool—it’s about choosing the tool your team will actually use to get the job done effectively.
Testing tools spark passionate debates—what’s your perspective? Comment below to share your experiences with Selenium, Cypress, or Playwright and how they’ve impacted your team’s testing efforts.
Note: This post is not intended to be a comprehensive guide or a detailed comparison of Selenium, Playwright, and Cypress, nor does it delve into their respective pros and cons. Instead, my goal is to highlight why Playwright and Cypress are gaining momentum in adoption. Based on my experience, these tools resonate more with teams aiming to bring engineers deeper into the testing sphere, fostering greater collaboration and shared ownership of quality.
Thank you for this post.
I was actually struggling recently with cypress integration to CI/CD.
I was able to optimize my e2e system test suite from 7 minutes to 10 seconds (so far in my experiment I managed to optimize around 10% of our test suite). I have mocked all the external dependencies (APIs, cloud resources, remote databases). I described it here:
https://open.substack.com/pub/maxpiechota/p/introducing-twin-stubs-for-integration?utm_source=share&utm_medium=android&r=2jrq6c
So my system was able to go through the user journey within few seconds.
It was great for optimizing Lead Time to Change metric.
But that was possible ONLY for the API tests.
When I wanted to employ our UI tests (with Cypress) it turned out impossible.
System route handler was responding in a fraction of second but the html rendering for cypress was taking seconds.
So the whole test from 10 seconds grew back to minutes.
And parallelization wasnt an option too, because the CI machine was blowing up having only 10 parallel cypress tests.
You mention using selenium on CI. Any insights on how to do it so the full test suite doesnt take hours?