Breaking news: A recent scientific study by Jennifer K. MacFarquhar et al., investigated an outbreak of acute selenium poisoning. It was found that selenium can have toxic effects at high doses. That’s disappointing, but definitely not unsurprising, since it just confirms Lenntech’s view that high concentrations of selenium introduces “scalability” issues (in a sense).

Time to put our cards on the table. These studies aren’t talking about software testing; they are talking about chemistry. They aren’t talking about the browser automation framework (Selenium); they are talking about the chemical element (selenium). So, why am I writing about them in a software testing blog? Well, although these two things are not physically related to each other, their effects on human beings (especially software testers) are not worlds apart.

First, let’s sort a few things out before we get back to this story.

Selenium is not a software testing tool

Selenium is not a software testing tool. The key word here is testing. Selenium is just a(nother) tool, and so Selenium (like any other tool on planet earth, including tools by Tricentis) doesn’t deserve to be called a testing tool. Even the idea of calling a tool a testing tool seems paradoxical – but it’s common language, and so let’s ignore that for now.

The important point is that testing is all about evaluating software by learning about it through exploration and experimentation. As such, testing is not (exclusively) about tools; testing is a process of exploration, discovery, questioning, investigation, modeling, observation and (most importantly) learning—thanks a ton to Michael Bolton (and friends) for bringing that “testing vs checking” message home. So, testing is, always has been, and always will be a search for information to close the gap between what we know and what we don’t know in order to reveal problems in our products. That’s how Cem Kaner put his finger on that problem.


Tools can amplify testers’ power (or their weaknesses)

Tools are extensions of us. Tools can (but do not necessarily) extend our human testing capabilities. Tools can assist, amplify, and accelerate our testing tasks—and so tools can also amplify our mistakes. As such, we need to be really careful that these tools don’t enable us to perform bad testing faster than ever. Again, this holds true for every tool (including Tricentis software testing tools). Nevertheless, we shouldn’t underestimate the role that tools play in our interactions with applications under test and in the testing effort.


With Selenium, it’s all up to the tester (for better or for worse)

Let’s look at this from a very specific angle: Automation. Selenium says: “Selenium automates browsers. That’s it! What you do with that power is entirely up to you.” Well, this absolute freedom definitely has its benefits, but it also brings a variety of critical problems, which we shouldn’t just sweep under the rug.

What Selenium provides is a coding framework, and that framework (like any other coding framework), has a one single goal: to make coding more efficient. That’s it. No more, no less. This means that when you use such coding frameworks in your testing projects, testing becomes more of a coding challenge than a testing challenge. I know this sounds paradoxical, but it’s the truth, the whole truth, and nothing but the truth.

Undeniably, the coding efforts required to create (and maintain) a stable, flexible, modular, data-driven, readable (keyword-driven), and maintainable framework is gigantic. If your test automation framework is expected to automate multiple different technologies and platforms (e.g., enterprise environment), it’s even worse. After investing in these huge coding efforts, testing is all-too-often just reduced to coding, and confused with coding.

Since you then constantly have to have access to technical people (coders, not testers) to tame these beasts (maintain frameworks), you might wonder: Well, how do we ever become better at testing (revealing problems) when we have to focus on hiring people who are better at coding (automating checks)?

The answer is simple: You can’t!

When you rely on self-made automation frameworks such as those based on Selenium, the related maintenance issues will kill your project. The lesson I learned while writing all these frameworks in the past is that more time spent on coding unfortunately means less time spent uncovering those tricky defects really impact the end user experience.


Tying it back together

Please don’t get me wrong. I think that Selenium provides a fantastic (an absolutely fantastic!) framework to write automation. However, leaving so much freedom/complexity/uncertainty in the hands of the tester becomes a significant hurdle at the enterprise level.

In conclusion, I’d like to propose that selenium (chemical element) and Selenium (coding framework) can be jointly described by:  “When animals (testers) absorb (use) selenium (Selenium) in high doses (enterprise environments), severe health impacts  (maintenance and scalability issues) are likely.”

P.S.: Want to escape from this dilemma? If so, then have a closer look at this.

Stay connected– subscribe

One Comment

  • Jay says:

    Great write-up. Emphasizing coding challenge over testing challenges creates headaches and confusion. Dividing and focusing on each area is key to a healthy product.

Leave a Reply