Picking the right test automation suite is an important part of your development life-cycle. Many developers choose the old open source standby, Selenium. It has been around a long time. And its age is starting to show.
What is Selenium?
The History of Selenium
In 2004, Jason Huggins developed Selenium as an internal tool for ThoughtWorks. Other ThoughtWorks testers and programmers teamed up with him to improve the app testing tool. When Paul Hammant joined the team, he steered the development process to produce the second mode of the tool's operation that later became Selenium Remote Control (SRC) and open-sourced it the same year.
In 2006, Shinya Kasatani from Japan donated Selenium IDE to the Selenium Testing Project. He had developed Selenium IDE, hoping to create a Firefox extension that would run as a record-and-playback automation feature for the browser. Ultimately, he hoped that this tool would speed up the process of developing testing tools.
In 2007, Jason Huggins joined Google as a developer. He continued working on developing and stabilising Selenium together with other developers from Google. On the other hand, Simon Stewart of ThoughtWorks created WebDriver, a superior tool for web automation.
He later met Google's development team at a Google Test Automation Conference in 2007, where they agreed to merge the two tools into Selenium 2.0 or Selenium WebDriver. The tool continued to be improved, with Selenium Grid being developed in 2009 by Philippe Hanrigou of ThoughtWorks.
Selenium Grid significantly reduces test execution time as it allows several tests to run concurrently on any number of remote or local systems. As an open-source tool, it works the same way as an internal or private Google cloud for anyone using Selenium RC.
Why is it time to move past Selenium performance monitoring?
When Selenium first came out, it was a game changer. But that was many years ago, and the game has changed again. Selenium remains popular because it is just feature rich enough to justify its cost; it's free. The open source tool lacks some modern features, but teams put up with it to save costs. However, there are a number of reasons why you are better off spending the money to move to a more robust test automation suite. Below is a list of the most common issues you'll find with Selenium:
Disadvantages of Selenium
- As a web-testing tool, it does not allow users to run mobile or desktop application tests.
- Tests run on Selenium are unstable. Previous versions of a web App may be affected when you run a test on a new version.
- Users do not get reliable technical support. As an open-source tool, technical support is not structured or centralised since anyone can volunteer to offer technical support. This is not reliable since not every developer understands the testing tool well enough to provide technical support. Besides, you may not get anyone willing to give technical support when you need it.
- Selenium users cannot run tests on images.
- Running concurrent tests on different browsers requires a user to be skilled in doing so.
Below we detail these issues and provide background for our solution:
Limited to browsers
Being based on a technology called WebDriver should give you a hint that Selenium isn't going to do much for you if your application does not run in a web browser. The tool is specifically designed to control web browsers and only web applications. Even if your company is developing a web application, unless you don't develop for any other platform, Selenium will only fracture your automation workflow.
While there are some add-ons that will allow you to control mobile apps, these add yet another layer of uncertainty to the process. One that will suffer from many of the same problems that we will discuss later on.
Having a testing solution that works on any type of application will allow your testers to have a consistent platform to use across all of the projects that they work on. This also means a consistent workflow for everyone who relies on output from those testers, from management receiving progress updates to developers receiving bug reports.
Requires programming skills
Your testing team might not be proficient coders. With Selenium, that puts them in a bit of a bind. Tests in Selenium are performed by programming the software to control the web browser. This means that your testers are going to have to learn a new skill, or you are going to have to hire testers who already have some coding skills.
More than likely, hiring testers with this extra level of experience will increase your labour costs. Expecting non-coders to learn programming can result in weeks of delays as they get up to speed on the skills needed. Programmers paid at tester wages, or testers forced to become coders, are also more likely to make mistakes with the code. This means more delays, or potentially buggy software releases.
Even worse, some companies have found that testers tend to only code tests for the most basic of functions. Testing edge cases or complicated scenarios were either out of the skill range of the staff or outside of what deadlines allowed for. Programming tests by hand takes time, and sacrifices need to be made when a crunch is on. Unfortunately, it is the edge cases that often hide the most bugs. Leaving those untested can be disastrous for a product launch. Only a no-code solution could change this scenario.
Provides no tech support
Selenium is still very popular. This means that there is an active community with tons of great tutorials and resources for finding help. But any help you get will be coming from the user base, not the developers. If you have custom requests, or problems that are not often encountered, getting help can take a long time.
While it is possible to contract out to consulting firms when the need arises, this adds a cost to a product where the primary benefit was that there were no costs.
Has no native reporting capabilities
The results of tests need to be communicated to other parts of the team. We mentioned earlier how project managers and developers need access to the output from testers. In the case of Selenium, there is no native output! Testers must rely on third-party or in-house solutions to generate the type of visual reports that managers like to see and the type of detailed reports that developers need to effectively fix a problem.
Relying on third-party solutions adds yet another link in the chain of things that can go wrong and people that can be held accountable when they do. Like the add-ons to support testing on more than just browsers, you've now added yet another aspect to your testing that can potentially suffer from many of the problems already mentioned.
Maintaining tests is time-consuming
We've already talked about how much time it takes to code the tests. But the work isn't always done with the code is written. At some point, you are going to make changes to your software. This means ensuring that all of the tests still function as they should. One changed reference could break many parts of your code.
With Selenium, your testing suite essentially becomes another application that must be updated and bug tested alongside the application that you are using it to update and bug test! This takes time, adds frustration, and increases the chance of error.
With 2 Steps, all of these problems are solved for you. You can easily create new tests, on any type of application, simply be recording yourself performing the action. Changes to the underlying source code have no effect on your testing suite. You can generate useful reports and analytics, as well as video of problems that occur so everyone who needs to be informed, will be. You can check our article Alternatives to Selenium on Splunk for further information.
If you still have questions, you can feel free to contact us at any time. We'll be glad to answer any questions you might have!