Selenium is an open-source tool that automates web browsers. It provides a single interface that lets you write test scripts in programming languages like Ruby, Java, NodeJS, PHP, Perl, Python, and C#, among others.

Start Automating for Free

Here’s how those components work:

A timeline of major events in the evolution of Selenium from an in-house side-project to an open-source industry standard in browser automation:

2004: Making history in two parts (from Selenium A to B)

• Jason Huggins of ThoughtWorks needs to test his web app’s front-end behavior across different browsers.
• He develops a tool that works by injecting JavaScript underneath the webpage, allowing the tester to write code that could ‘automate’ front-end user interactions. This became the JavaScript TestRunner.
•  Although the JS-injection approach couldn’t naturally replicate user interactions (via keystrokes/mouse movements), it was a workaround for the ‘same-host origin policy’, which prohibits external JavaScript code from accessing elements from a domain it didn’t originally reside in. Nonetheless, the tool is positively received by in-house developers and ThoughtWorks’ clients alike.
• The tool is open sourced due to popular demand.
• To eliminate the need for JS-injections, Huggins, along with colleague Paul Hammant, discuss the possibility of a ‘server’ component. This server would act as an HTTP proxy and trick the browser-instance into believing that the test script and the web app under test are from the same source.
• They develop the server component in Java and the original client-side driver (TestRunner) gets ported to Ruby.
• This is the original Selenium. Known as Driven Selenium or Selenium B in the evolution timeline.

2005: Selenium RC (Remote Control)

• Elsewhere (at Bea, specifically), Dan Fabulich and Nelson Sproul begin working on the driver coder. They eventually mold it into a standalone server that bundled MortBay’s Jetty as HTTP proxy.
• This becomes ‘Selenium RC (Remote Control)’ or Selenium 1.0. Before we cut to 2.0, there is another significant development in the form of…

2006: The Selenium IDE

• Shinya Kasatani wraps the Selenium driver code in an IDE module in Firefox browser.
• When it works, he finds that he can run a functional ‘live test’ on a website—interacting with the browser (as a user would); recording/replaying the interactions and debugging as needed.
• Kasatani donates this tool to Selenium project where it becomes known as the Selenium IDE.

2007: The Selenium WebDriver (Selenium 2.0)

• Back at ThoughtWorks, Simon Stewart diligently codes up separate ‘driver’ clients for every popular browser, so they’d all support automation with native browser capabilities.
• It pays off. The project becomes famous as the WebDriver.

2008: Multiply by ‘n’: The Selenium Grid

• At ThoughtWorks, Philippe Hanrigou creates a server which would allow testers to access and run tests on browser instances on any number of remote devices.
• This becomes known as the Grid. Cut to…

2016: Selenium 3.0

Selenium RC gets deprecated and WebDriver becomes standard implementation—aka Selenium 3.0.

2019: W3C Protocol

WebDriver becomes a W3C standard protocol.

2021: Selenium 4 released

On October 13, 2021, Selenium 4.0 was officially released.

Imagine that a manual tester has this scenario: Checking whether the web app’s signup page (www.example.com/signup) validates input strings and registers a user successfully in latest versions of Chrome and Firefox, on Windows 7.

Assume that the signup page has these input fields—username, email address, and password. The tester will get a Windows 7 desktop and follow these steps, consecutively, on latest versions of Chrome and Firefox:

1. Enter the URL in the address bar (www.example.com/signup)
2. Enter an invalid string in each input field (email, username, and password)
3. Check whether the input strings were validated against corresponding regexes and any pre-existing values in the database
4. Enter ‘valid’ strings in each input field; click Sign Up
5. Check whether “Welcome, ‘{‘username’}’“ page showed up
6. Check whether the system database created a new userID for ‘{‘username’}’
7. Mark the test ‘passed’ if it did, ‘failed’ if the signup feature broke anywhere during the test.

That’s a very basic system test. In the real world, testers are more likely to be checking all user workflows on www.example.com for breakage, on as many OS-browser combinations as needed to meet the benchmarked compatibility standards.

Depending on the number of manual testers (and thoroughness of test cases), it may take anywhere between hours to weeks to be sure that the web app is fully functional.

Modern developers and product teams don’t have that kind of time to allot for testing, but they can’t set aside exhaustive testing in a hurry to release either. This is why they super-charge their testing with automation, powered by Selenium.

Run a Selenium Test

Types of testing that are commonly automated with Selenium are:

Compatibility Testing:

Done by QA professionals/Testers to ensure that the web app meets performance benchmarks on different browser-OS combinations. For example, testing on different devices (mobile and desktop) to ensure that the front-end fits to scale (responsive); testing on different browsers to see if video ads render on the pages as they should.

Performance Testing:

Series of tests done by QA professionals/Testers to ensure that the project meets performance benchmarks set by the stakeholders. Tester writes a script that checks whether all elements on homepage load within 2 seconds on different browsers/browser versions.

Integration Testing:

Done by developers to verify that units/modules coded separately (that work on their own), also work when put together. Parallel Test Calculator, for instance, has separate layers. UI takes input and business logic calculates the output—then sends it back to UI to display. The tester could verify whether they are able to relay data/output when integrated.

System Testing:

aka Black Box testing. Done by Testers/QA professionals with no context of the code or any previously executed tests. Typically centered on a single user workflow. The check-out process on a product website, for instance, comprises of: validating user credentials, fetching products from the cart, checking their availability, and validating payment details—before redirecting to the bank website. The tester could write a script to verify that the entire system is functional.

End-to-end Testing:

Also done by Testers/QA professionals, typically from the user’s point of view. The aim is to verify that all touchpoints on the web app are functional. From the previous example, the tester could write a series of test cases to check that sign-up, product search, checkout, review, bookmark, and all other features function as intended (and fail when invalid values are entered in input fields).

Regression Testing:

A series of tests done to ensure that newly built features work with the existing system. From the same example, say the product website launches a new feature (promotional codes) that automatically apply to eligible items before checkout. The tester could write cases to verify that it doesn’t break the rest of the checkout feature.

Well-written test suites can also automate Smoke and Sanity testing with Selenium.

Short answer: Everyone who cares about the state of their web app.

Part of the reason why Selenium is so popular is its flexibility. Anyone who codes for the web can use Selenium to test their code/app–from individual freelance developers running a quick series of tests for debugging to UI engineers doing visual regression tests after a new integration.

In an enterprise environment, testing with Selenium falls under the purview of QA engineers. They are tasked with writing focused, non-flaky (i.e., deterministic) scripts to maximize test coverage and accuracy, refactoring old test suites for newer versions of the project, and maintaining test infrastructure (from the Hub to the test-case library).

They would be the ones creating comprehensive test suites to pinpoint ‘show-stopper’ bugs and advising stakeholders about updating performance benchmarks for the project. Their end goal is to ensure maximum test coverage and efficacy, which in turn boosts the overall productivity of the engineers at work.

Most desktop/ mobile browsers today have built-in support for automation testing with Selenium. Consumer browser vendors like Firefox, Chrome, Safari, IE, and Opera develop and ship their browser’s drivers.

In the years since it was first open-sourced, others have contributed to the Selenium project by adding third-party drivers for specialized browsers like BlackBerry 10 and HtmlUnit, as well as bindings for integration with development frameworks like PhantomJS, Qt, etc.

You don’t need to download Selenium (so to speak) like a piece of software. You will, however, need some of its components in order to run tests on automated browser-instances on your own device.

To get a hang of this, simply head over to Automate Documentation. Pick a language and/or framework you typically work with. Follow the steps to install the components you’ll need, and run a couple of sample tests. You’ll get a functional understanding of Selenium automation testing in no time.

Ready to take your web app through a real testing mill? Take a look at Automate, which gives you instant access to our Selenium Grid and 3000+ browsers on real desktop and mobile devices.

Selenium recently released the latest version of the tool – Selenium 4. This upgrade comes with features like an enhanced Selenium grid, upgraded Selenium IDE3, relative locators in Selenium 4, Chrome debugging protocol, better Window/Tab Management and so much more.

Watch the below webinar by Simon Stewart, Project lead and creator of Selenium WebDriver,  to understand the features that are available in Selenium 4 and more.