Should We Be Using Playwright?

Manager: “Did you see the latest Playwright release notes?”

QAE: “Yeah, it does screencasts now! Isn’t that great!?”

Manager: “It is. So, with all these new features in Playwright, is it the right tool for us to be using right now? Why are we still running the majority of our tests using Selenium?”

QAE: “Ummm…”

Conversations like this are happening all around the world at the moment. If you listen really hard, you can hear the QAEs’ minds coming up with reasons:

The honest reason: “I’ve always used Selenium. It’s what I know how to use.”

The slightly annoyed reason: “I’ve spent the last year making the tests stable enough to support continuous delivery. When would I have had time to migrate to Playwright?”

The perplexed reason: “When did you suddenly become interested in test frameworks?”

And, of course, the reason nobody wants to give:  “I…don’t know?”

And yet, it’s a valid question, especially if your stakeholders are paying any attention at all to the development process and are curious about why the UI tests seem to take so much longer than every other part of the development pipeline.  Why don’t we switch to Playwright?  And if you’ve been a QAE for more than a few years, Selenium has been your go-to tool for browser automation for a long time, so the question might be a bit uncomfortable.  You know Playwright is highly visible in the industry right now. You know it has the backing of Microsoft and so there’s an awful lot of support and development going into it.  Migrating your whole test process from Selenium to Playwright is going to take time and be really painful, so there would need to be very good reasons to put that time in.

So, are there good reasons to switch?  Are there good reasons to stick with Selenium? Your stakeholders want to know.  You’re the expert. Everyone’s looking at you.  What’s the answer?

At first glance, Playwright seems to be holding all the cards. Built-in auto-wait is great, as is the tooling and the isolation, not to mention all of the other bells and whistles that get added with every major release.  Why not migrate?

Well, it turns out there are some good reasons not to take that plunge.  At least, not all at once, and not right away.  For all that Playwright is accomplishing in the test automation space right now (and it’s accomplishing a lot!) there are some genuinely good reasons to stick with the old, faithful browser automation that you know. And understanding those reasons will not only give you the ability to answer management’s question, knowledgeably, but it will give you a deeper understanding of browser testing in general, and make you a better QAE in the future.

That’s what our workshop “Selenium vs Playwright: the Ultimate Showdown” is all about. For two days, you’ll get hands-on, practical examples of some of the major differences between these two browser automation tools.  This isn’t a bullet list of advertised feature sets.  You’ll get a deep-dive analysis of how these two giants of the industry work at a fundamental level, and you’ll get an excellent grounding in why a software development team would want to choose one tool over the other. Anyone can look at the release notes and product page: the QAE is the one who knows the mechanisms at play under the hood and can answer the question: “Should we be using Playwright?”

If this sounds like information you want to know (and you’re in or near the Southampton area) check out the workshop page and let us know you’re interested in attending.  If we don’t already have a course scheduled, we’ll let you know when the next one’s coming.

TestCraft Academy: practical experiences in test automation.