A Brief History of the Selenium Testing Framework

Ever wonder where Selenium (the testing framework, not the mineral you get from eating clams) came from? Here’s a short history of the technology, from its origins more than a decade ago as a proprietary tool through the present era of Webdriver.

Selenium originated in elder days - by which I mean 2004 - as a tool for testing web applications. It was developed by Jason Huggins, a programmer at ThoughtWorks.

That Selenium originated at ThoughtWorks is interesting. While no one in 2004 was talking about Agile infrastructure, ThoughtWorks was the place where Martin Fowler made his career. Fowler went on to become one of the major thought leaders behind the migration to microservices. While Fowler can’t take credit for Selenium, it seems fitting that the tool, which is an important part of automated testing for DevOps-inspired workflows today, originated in the same place from which the Agile infrastructure revolution later emerged.

At first, Selenium was used only internally by ThoughtWorks employees. But that changed by the end of 2004, when the tool was open-sourced.

I don’t know exactly when Selenium became an open source tool, since the earliest emails relating to the open-sourcing do not seem to exist anymore (at least not publicly). But it was apparently no later than late November 2004. That’s when the first extant Selenium development emails were being exchanged, and people were talking about checking out the Selenium code via Subversion.

Selenium at this point remained an imperfect tool. It suffered from some bugs that affected testing for certain browser environments. And thanks to the inefficiencies of the waterfall-style software development practices of the time, bug fixes were slow to reach users. As a Selenium user noted on November 29, 2004:

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

Last but not least, the move placed Selenium within the rapidly growing stack of open source applications at the time. The early 2000s were the era when companies like Red Hat were showing that Linux and other software that was given away for free could have huge commercial value. It was also when open source web browsers, namely Mozilla Firefox, and word processors, such as OpenOffice, were giving closed-source tools a run for their money. And open source web browsers like Apache HTTPd had already held a majority of market share for years. Against this backdrop, open-sourcing Selenium only made sense.

Within a year of its release as an open source tool, Selenium had evolved significantly. 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.

The evolution of Selenium during this period was helped by the fact that Jason Huggins, the original Selenium developer, moved in 2007 to Google, where he was able to continue work on the tool.

But ThoughtWorks was not out of the picture yet. Also in 2007, another ThoughtWorks employee, Simon Stewart, developed another testing tool for web apps called WebDriver.

WebDriver's debut signaled a desire for features that were not available in Selenium. And for a short time, the two tools competed.

But in 2011, the projects were merged to form one web testing tool to rule them all. The combination of Selenium and WebDriver became Selenium 2.0, which debuted in July 2011. The new release paired the WebDriver APIs that are familiar to Selenium users today with the original Selenium feature set.

The demands of automated testing continue to change. It’s a safe bet that Selenium will, too.

One important trend that is likely to shape Selenium development going forward is the demand for ever-more efficient automated testing. The Selenium ecosystem has offered some automation options for a while thanks to Selenium Grid and other tools. But as the DevOps movement increases pressure on development teams to test and deliver software even faster than they already do, techniques for speeding tests, such as by offloading them to the cloud and running them in parallel, will remain key.

Shift-left testing has also become an important part of the automated testing conversation. Selenium is already well suited for shift-left testing, which refers to the practice of performing tests earlier in the development cycle, in order to identify bugs before they slow development. But Selenium users have to choose to take advantage of Selenium in the right way for this purpose.

Optimizing Selenium today is easier thanks to a rich ecosystem of plugins and integrations that simplify the task of working Selenium into the software delivery pipeline. Since development workflows are now more complex than they have ever been, and will probably grow yet more complex over time, the ecosystem surrounding Selenium is poised to remain essential in helping Selenium to remain relevant for modern application testing.

Want to learn how to use Selenium? Sauce Labs now offers Selenium training via online and on-site instructor-led classes that are focused on getting you up to speed quickly. Our classes are small and interactive, with a combination of lecture, demos, and hands-on exercises - learn more. 

Selenium Conference 2016 London tickets are now on sale - join hundreds of other Selenium experts this November 14-16. Chris Tozzi has worked as a journalist and Linux systems administrator. He has particular interests in open source, Agile infrastructure and networking. He is Senior Editor of content and a DevOps Analyst at Fixate IO.