- The Platform Configurator
- Getting Started with Selenium for Automated Website Testing
- Getting Started with Appium for Mobile Native Application Testing
- Selenium Bootcamp by Dave Haeffner
- Appium Bootcamp by Dave Haeffner and Matthew Edwards
The Tedium of Testing and the Genesis of a Better Way
In the early days of website testing, everything was done by hand. You would start from a set of functional requirements, or some architectural specifications, or maybe a prototype website, and you would write out scripts for every interaction that you wanted to test, from logging in, to clicking on links, to going through all the permutations of transaction processes. You would then hand those scripts to a team of Quality Assurance testers, and it was up to them to slog through all those clicks and data field entries, making notes of the bugs they found as they went. Testing was a tedious process that took a long time, and so lots of development teams would just skip it, or implement it in the most minimal of ways.
In 2004, while working at ThoughtWorks, Jason Huggins had an idea: what if you could could find a way to take those scripts and make them understandable by the browsers that you wanted to use in your tests, so that the browser could do the work of all those clicks and entries? Out of this idea, working with colleagues at ThoughtWorks and, later, Paul Hammant, Selenium RC (Remote Control) was born and released in that same year as an open source tool. When Jason later joined Google, he continued work on this project with colleagues like Jennifer Bevan, while his former colleague at ThoughtWorks, Simon Stewart, had also developed a test automation tool called WebDriver. In 2009, the project teams decided to merge Selenium RC and WebDriver, and Selenium WebDriver, also know as Selenium 2.0, was released.
Acclerating the Development Cycle
Selenium 2.0 solved the problem of tedium in testing, but it didn't fully solve the problem of time. While scripted interactions could execute at much higher rate than human interactions, they still took some amount of time to execute. If you were running 100 tests that took an hour to execute, that was probably a considerable improvement over the days or weeks it had previously taken. But if you had to run that same set of tests multiple times, for each combination of platform/operating system/browser that you wanted to test against, it was easy to see how those hours could potentially stretch into days. And if you had to run those tests as part of every build, you were facing a very large boulder in the path of your development process.
The solution to this came from Philippe Hanrigou at ThoughtWorks, who in 2008 released the open source Selenium Grid, which provides the ability to run multiple Selenium tests in parallel on any number of local or remote systems. Now, if your tests took an hour to run for one platform/operating system/browser combination, they would take an hour, total, to run for every combination you wanted to test against. The boulder was broken, and the way opened toward continuous integration and delivery.
Sauce Labs and Your Own Personal Selenium Grid
Selenium Grid was a breakthrough for DevOps, but it there was still the challenge of setting up the system. Even with virtualization, maintaining the grid with every new update or release of its components was a chore out of the reach of almost anyone except corporations who could invest in the necessary people and equipment. The next breakthrough would have to be in finding a way to provide this kind of service to everyone, from open source teams of three people up to the most massive enterprise development organization.
In 2008 Jason Huggins, Steven Hazel, and John Dunham teamed up to found Sauce Labs, and to offer a service that would enable everyone to have their own personal Selenium Grid. Since then Sauce has worked to develop other products and services that enable everyone to build more robust websites and mobile applications.