lecture 16 of 160 completed

Should your team still be using Selenium?

Every Selenium team faces this question. Here is how to answer it fairly, in both directions.

If you work with Selenium, someone will eventually ask why you are not using Playwright or Cypress. It might be a developer, a new manager, or a candidate in an interview. You need a real answer, not a defensive one.

Let me give you both sides.

Selenium is still the right choice when:

  • Your team does not write JavaScript. Selenium has proper support for Java, Python, C# and Ruby. A Java team will maintain a Java suite far better than a JavaScript one they are uncomfortable in. This is the single strongest reason, and it is a good one.
  • You need browsers or platforms other tools do not reach, including older browsers some enterprise customers still use.
  • You have a large, working suite. A suite that catches real bugs today has value that a rewrite would destroy for months.
  • Your organisation needs a W3C standard tool with long-term support. In regulated industries this is sometimes a hard requirement, and Selenium's age and standardisation are advantages.

Selenium is the wrong choice when:

  • You are starting fresh with a JavaScript team. Playwright will give you faster, more stable tests with less code. Choosing Selenium here out of habit is a mistake.
  • Your suite is mostly sleep calls and nobody trusts it. You are going to rewrite those tests anyway. Rewriting them in a tool with built-in waiting is nearly the same amount of work and a much better result.
  • You need parallel runs and cannot maintain a Grid. Newer tools handle this out of the box.

Now the migration question, which is the one that actually costs money.

Usually the answer is no. A migration takes months and gives you exactly the coverage you already had. That is very hard to justify, and I have seen teams start one, get half way, and end up maintaining two suites for a year.

Migration makes sense in two situations. First, when Selenium blocks something you truly need. Second, when the suite is already so unreliable that you are rewriting it regardless. In that second case the migration is nearly free, because the work was going to happen anyway.

If you do migrate, do it gradually. Keep both suites running. Move the most valuable tests first. Never turn off the old suite until the new one covers the same ground.

And if you decide to stay, say why out loud, in terms of the team and the product. "We stay on Selenium because the team writes Java and the suite catches real bugs" is a senior answer. "We have always used Selenium" is not.

Remember this: be able to argue both sides. The engineer who can explain when their own tool is wrong is the one people believe.

No problem for this lecture. This is a discussion to have with your team.