Director of Software Engineering | Quality Strategist | Podcast Co-Host
Selenium has been the gold standard for automated browser testing for good reasons: 🔹It's open-source and free 🔹 It has multi-browser and multi-platform support 🔹 A robust community backs it. But here’s the catch, it has: 🔹 Slower execution than modern tools 🔹 No built-in reporting or test management 🔹 A steep learning curve, especially for engineers outside testing. That last point is critical. Here is why: Recently, we discussed a report at work: The State of Front End Development by The House of Software. One stat stood out: Cypress ranked second. Playwright came in fifth. Selenium? Nowhere in the top 10. At first, this was surprising. Selenium has been a staple in browser testing for years. So why the low ranking? The answer was in the survey details. The respondents weren’t test professionals—they were 6,000 developers. These were front-end engineers focusing on unit and integration testing in modern workflows. While tools like Jest unsurprisingly topped the list, Playwright and Cypres' high rankings also confirmed what I’ve observed firsthand: their developer-friendly design makes them better suited to modern teams and workflows across the spectrum of the team, not just for testers. In my experience, here are some of the reasons why these tools are gaining traction amongst engineers: 🔹 Streamlined setup makes them easy to adopt. 🔹 Seamless CI/CD integration aligns with modern workflows. 🔹 Intuitive design and built-in debugging tools reduce friction for new users. On one project, I faced a common challenge: too many engineers, too few testers, too little time. Our solution? Make quality a shared responsibility across the team, including engineers on debugging and investigation of automation failures. Here’s what worked: 🔹 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 🔹 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. 🔹 Engineers took the lead in investigating E2E test automation failures: instead of waiting on testers, engineers analyzed issues with the tests, identified bugs, and resolved them. Sometimes, it’s not about the "best" tool—it’s about the tool your team will actually use. What has your experience been with getting engineers involved in the automation of checks within your teams?