Enable javascript in your browser for better experience. Need to know to enable it? Go here.
Blogs Banner

Happy 10th Birthday, Selenium

Selenium as a technology is now 10 years old. Thoughtworks is proud to have created and open-sourced what is now the defacto-standard for cross platform cross browser web-app functional testing. We’re also proud to have released it as open source for the greater good. 

In honor of its 10th birthday, we put together the below timeline. Here’s to another 10 successful years.


We were making a “Time & Expenses” web application to replace a Lotus Notes version for internal use. Jason Huggins (@hugs - then in Thoughtworks tech support), was charged with building it. With colleagues he made an early version of Selenium that could obey scripts encoded in HTML tables (now known as Selenium 1 “core” mode).  That’s where I came in (Paul Hammant @paul_hammant). I’m a Thoughtworker from the consulting practice.

When I took a look, at Jason’s suggestion, I agreed that it was a game changer, but went to work specifying a second mode of operation whereby Selenium could be remote steered over TCP/IP (using techniques that would go on to be described as “Comet”), from Java, C#, Ruby, Python and others. That was “driven” mode or “Selenium B”, with the core mode known as “core” or “Selenium A” (there was a short-lived vitamin theme).

Jason and I share co-creator credits for Selenium (1.0), but many Thoughtworks staff helped with the implementations in different languages, robustness, and general feature set of Selenium in the early days. Nowadays, the B mode of operation is known as “Selenium Remote Control” or Selenium RC for short.

We also open-sourced Selenium for the world to use and contribute to. Originally it was a Thoughtworks maintained GForge portal which we’ve long since turned off, even if the code survives in Github. Bret Pettichord (@bpettichord), better known for WATIR (then a Ruby+IE only functional testing technology) as a Thoughtworker helped us promote Selenium to the testing community.


Pat Lightbody (@plightbo - who was secretly building a startup that used Selenium) with Dan Fabulich (@dfabu) and Nelson Sproul (@nasproul), both then at Bea, suggested that Thoughtworks consume a very large patch that changed ‘B’ into Remote Control permanently. Whereas ‘B’ was two processes on an OS - the script running the test and the browser itself, RC introduced a third process that sat in the middle of the two, and allowed more than one machine to be involved in the execution of Selenium tests. This included tests being scripted from, say, Mac and executed on Windows in IE.  In accepting the patch, leadership of the project immediately became a committee, with consensus being the agreed way to manage it, lasting to this day.

Also in late 2005, in India rather than the US, Thoughtworker Narayan Raman (@narayanraman) started ‘Sahi’ with Thoughtworkers in India as an alternate way of scripting the functional testing of web-apps. Sahi’s features included a recording capability that Selenium did not have as well as a different approach for describing a test, but at that time wasn’t a many-language proposition. Today Sahi continues, and “Sahi Pro” has been commercialized by Narayan after he left Thoughtworks. The Selenium team soon copied many of the advances of Sahi, including its ability to inject code into the page to enhance testability.

Outside Thoughtworks and the Selenium committee, Shinya Kasatani (@shinya) in Japan wrote a Firefox plugin that effectively wrapped the “core” code into an IDE that would allow record, edit and playback of Selenium scripts. In a follow up release IDE was able to export scripts to Java, C#, Ruby and Python, to allow advanced uses to continue scripts with Selenium RC (and any browser) as the target. Recording, of course, was one the things that Sahi did very well.


After many proof of concept experiments at the end of 2006, Simon Stewart (@shs96c - a Thoughtworks consultant in Australia) started “WebDriver” in early 2007. By design this competing technology was able to overcome one of the major problems with Selenium RC by turning the browser into a legitimate socket-listener for a remotely commanding process. Whereas RC kind of had one set of JavaScript code that could run in all browsers, WebDriver has idiomatically-correct extensions/plugins for each browser (that meant C++ code, or Java, or JavaScript, or C# with the same features for each each browser). It was better by design, but was an order more complicated to develop than Selenium RC/core. It was worth it because of the limitations that RC had, and it very quickly gained traction inside Thoughtworks and elsewhere. WebDriver also emulated Selenium RC from the outset, with a bunch of Selenium code utilized in the WebDriver binary. If you had a choice on a project, you would use the WebDriver mode of operation, instead of the Selenium RC mode.

The Selenium committee and Simon (by now a London Thoughtworker) bumped into each other a lot. During Google GTAC conference in 2007, Pat, Simon and Jason (by then a Googler) discussed a formal reverse-takeover of Selenium. RC (and Core) would become “Selenium 1”, and WebDriver would be “Selenium 2”. The reverse takeover came to be, with Simon and his team added to the Selenium committee, as we rested the old Selenium 1 implementation over a number of years, while preserving it in an emulation.


Thoughtworker Philippe Hanrigou (@ph7) created 'Selenium Grid' which allowed Selenium RC to be used in expanded capacity. Specifically RC browsers could be leased from an elastic capacity on remote machines. This included the potential for multi-threading tests in parallel from a single test invocation, and utilizing a large number of browser (multi-OS) elsewhere.  This was a clean-room reimplementation of what Pat had already done for his startup, and Jennifer Bevan had done privately for a very large capacity inside Google.


Google (with Simon on board) kindly “introduced” WebDriver in a engineering blog entry :). Jason left Google to launch a startup, SauceLabs, to do cloud testing.


By now, the browser makers were very much aware of the need to contribute to Selenium, or at least be respectful of it. David Burns (@AutomatedTester) contributed a lot to the Selenium2 codebase (Mozilla’s Firefox team would later hire this super star and be first class patrons of Selenium). Opera contributed their own implementation of WebDriver. The Chrome team starts to maintain an executable that acts as intermediary service for WebDriver steering of their browser. Those three are all platforms. Safari on Mac, IE and mobile versions of the key browsers are covered too.


Selenium has for a couple of years been the defacto-standard functional testing tool, with contributions from a hundred or more committers and contributors. All browsers, and all Operating systems is the still the goal. Just about every Thoughtworks mission uses functional testing with one of Selenium, Sahi or WATIR. Sometime idiomatically, or sometime via accelerating frameworks/libraries, including Twist that Thoughtworks has also made to lower the barrier to entry for QA professionals.

Pat has had a second successful (acquired) startup leveraging Selenium for performance testing in a elastic cloud capacity. Jason also has one that is still in its expansion mode for functional testing, again in an elastic cloud service. Simon works at Facebook, as ever, on Selenium-related master plans.

Selenium is now managed as part of the Software Freedom Conservancy which is a 501(c)(3) non-profit organization. You are very welcome to make donations there.

Did you miss Selenium's 10th Birthday Party in Chicago? Check out the video played after speeches. 

Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.

Keep up to date with our latest insights