The Origins of Selenium

Selenium originated in 2004 by Jason Huggins at ThoughtWorks. Jason was trying to figure out an easy way to automate testing of a time and expense web application.

When asked what name should be given to this tool, Jason gave a flippant, on-the-spot answer: the dominant product at the time was Mercury’s QuickTest Professional, so anyone who hated it and wanted to be “cured” would likely seek out the cure to Mercury poisoning… which is Selenium!

ThoughtWorks was where Martin Fowler first wrote about the migration to microservices (in 2003!). While Fowler can’t take credit for Selenium, it’s fitting that the tool–a vital piece for automated testing for DevOps-inspired workflows today–originated in the same place as the Agile infrastructure revolution.

Open Source Selenium

At the end of 2004, Jason released the tool to the open-source community. At this point, it suffered from bugs that affected testing for certain browser environments. And thanks to the waterfall-style software development practices of the time, bug fixes were slow to reach users. As noted in early bug reports, it was difficult to make the tool work consistently between Internet Explorer and the nascent Firefox.

Yet the fact that Selenium had become open source was a big deal. It helped to popularize the tool since anyone could use it for free, and anyone could also contribute to it to expand its feature set.

The move also placed Selenium within the rapidly growing community of open-source projects, such as Linux, git, Maven, and other vital free software projects. People realized that these tools had huge commercial value. It was also around that time when open-source web browsers (including Firefox and Opera) were giving closed-source tools a run for their money. Open-source web servers like Apache httpd had already held a huge piece of market share for years.

Selenium Grows Up, Meets WebDriver

Selenium evolved quickly. By October 2005, developers were dreaming up ambitious “grand plans” for the tool. They envisioned adding sophisticated new features that would extend Selenium beyond its original mission as a basic web app testing tool. Those included things like support for testing framed applications and cross-platform testing.

In 2007, Jason Huggins moved to Google, where he was able to continue work on the tool. But ThoughtWorks was not out of the picture yet! Also in 2007, a ThoughtWorker named Simon Stewart developed another testing tool for web apps called Selenium WebDriver.

WebDriver’s debut signaled a desire for features that were not available in Selenium. And for a short time, the two tools competed. In 2007, Simon and Jason participated in the Google Test Automation Conference (GTAC), where they held the infamous Steel Cage Knife Fight, during which they proposed combining the projects.

It took a few years, but the projects finally merged to form one web testing tool, with the ease of use of the WebDriver API but the versatility of Selenium. This became Selenium 2.0, which debuted in July 2011.

Selenium Design Goals

In those early days, the leaders fought to keep the design goals simple: create a single toolset for the automation of browser control across platforms. Even that simple-sounding goal was still quite complicated, though: Selenium supports five programming languages, four major browser platforms, and several sub-projects. This leads to some questions:

  • Why doesn’t Selenium offer API testing?
  • Why doesn’t Selenium have more robust reporting?
  • Why won’t Selenium return HTTP status codes?

The same answer applies to all three questions (and many more just like them): Selenium automates browsers. That’s it. It’s not strictly even a testing tool–it’s a robotic browser control mechanism, and the project has its hands full with even this simple mission. See below for a list of wrappers, frameworks, and partner projects that make Selenium more of a testing tool.

Selenium Present, Selenium Future

Selenium has changed drastically since 2011, but due to the strength of a beautifully elegant API design, a rigid adherence to backward compatibility, and a good succession of project leaders, the main aims of the project have stayed the same.

The most important development in the past 10 years is the emergence of WebDriver as the de facto–and de jure–standard for all web browser testing. This means that members of the Selenium project, the browser vendors (MicrosoftGoogleMozilla, and Apple), as well as test vendors (such as Sauce Labs) have all come together to agree on a meticulous set of requirements that will guarantee compatibility between Selenium code and all browsers.

No other test tool (CypressPlaywright, etc.) can make the same claim. While the chances are low, these tools suffer from the risk of changing browser internals, which could potentially break existing and future compatibility.

Recent additions to the tool are ease-of-use features such as relative locatorsfull-page screenshots, and an entirely redesigned Selenium Grid. Future plans include a more performant bi-directional protocol and more quality-of-life features included with the various language bindings.

Changes to the Selenium Ecosystem

With the constant evolution of web development tools and platforms, the need for testing tools to evolve is absolute. While Selenium has kept up with the compatibility issues within the web browsers, developers are demanding more and more around debugging, ease of use, and reporting features.

It is outside the design goals of the Selenium project to offer many of these things. For that, we rely on the extensive Selenium ecosystem of partner projects, including:

Selenium is Here to Stay

Used by millions, Selenium is truly the way the world tests the web. Despite the buzz from similar projects in the same space, Selenium’s adoption and growth have not subsided and, in fact, have accelerated. People sometimes have issues with consistency or stability, but the truth is that it’s a complicated tool that should be used in conjunction with tools in the ecosystem, not as a standalone tool. It will continue to be the standard in web automation for years to come, so supporting these member projects will work to everyone’s advantage!

 

Source: https://saucelabs.com/blog/a-brief-history-of-the-selenium-testing-framework