Using Selenium for automated functional testing

We are now in an age when it is accepted by most IT managers that Software Quality Assurance – and Testing/Validation & Verification in particular – is not only a desirable element in any project, but is actually an essential aspect that cannot be ignored if you want to remain competitive towards more SQA-mature rivals.

The cost of cutting corners usually arrives later, and with heavy interest. In extreme cases, it can make you go bankrupt if the fault has enough impact, but in an age of fast social networking and real-time news – damaging your reputation when your products fail is the most common setback.

Fortunately, it is now possible to rely not only on enterprise-class tools but also on simple, open-source free suites, which help refine the art from management of the initial requirements to test management, automation, defect management, and related practices.

Record and play

Development cycles are getting shorter and the ability to test rapidly in an agile mode going forward is what companies want. At LeaseWeb’s Cloud unit, we have been attempting to find a balance between test costs and coverage, and towards that, there has been an increased effort in areas like unit testing, test automation, and continuous integration.

Shorter periods do not necessarily reduce the risk of new functionality affecting existing functionality; in fact, with frequent releases, there is less time for regression testing. In this post, we will present a small introduction on how an investment on the automation of functional tests, especially regression suites has helped us move faster, without added risk.

Regression cycles can be a drain on productivity and absorb time that would otherwise be spent in other activities, including improving the test management process. Manual regression testing can also be a mundane and boring activity for most test teams, requiring concentration even when following a clear test plan or checklist.

Our team has realized the necessity to automate functional tests and has taken some initial steps:

  • We looked at our test suites and identified core test cases in very high risk/high impact areas.
  • Of the flagged tests, we determined which were more time-consuming on each development cycle, and of those, which would be better performed via automation, and which would benefit the most from experienced-based, human testing, especially when involving exploratory testing techniques. It was determined that the most time-consuming test runs were related to regression on a Bootstrap-frontend-framework based web portal used by our internal teams to manage our Cloud offerings.
  • A subset of the test cases were then selected for automation scripting, allowing us an initial level of coverage of about 43%.
  • With that in mind, we looked at several possible tools for automation, some strongly GUI-dependent, others relying on headless browsers. Both have their strengths and weaknesses, usually trading between ease of first write/maintenance and customization power.

For now, we settled on using Selenium IDE (Se-IDE), a free Firefox extension created by Shinya Kasatani of Japan that can automate the browser usage through a record-and-playback feature. It is both a recording tool and a simple, accessible IDE.

NNE-article1-1The main advantage of Se-IDE is its ease of use when quickly recording test cases by test teams with low-programming skill sets, as well as future easy maintenance. At the same time, it retains the ability to export tests to formats that can be used on Selenium 2 (formerly called WebDriver). In the first case, most interactivity occurs visibly on the browser, while in the latter, extra power is possible via direct control of the browser at OS level.

Even with Se-IDE having limited native functionality, its original commands can be expanded by directly coding JavaScript in the IDE window, should the user need it. In this first article, we will provide an overview of how Se-IDE can be used, with later articles/tutorials focusing on specifics like Element Locators and advanced tests.

Setting up

As a starting point, install the Selenium IDE plugin in Firefox. Selenium IDE has a plugin system that allows for easy extension and customization, with a few additional browser extensions and Se-IDE plugins that can prove useful:

  • Firebug and FirePath: These two extensions provide various useful tools for the Selenium scripter, but object identification will probably be one of the most useful.
  • Highlight Elements: This Selenium plugin allows much easier visual identification of objects being targeted during the execution of a script.


  • Stored Variables: Selenium does not natively provide a way to keep track of stored variables, so this plugin is quite useful.


NNE-article1-4Running the main Selenium IDE plugin

After running Selenium IDE, you can also configure dedicated extensions for the IDE. That can be configured in Options>General>Selenium IDE Extensions. Multiple extensions can be added, comma-separated:


Expanding Selenium IDE further via JavaScript user extensions

The following also prove useful:

  • Sideflow: Selenium does not natively provide a powerful way to control script flow. You can enhance that by adding labels, while cycles, GoTo jumps and so on, via the Sideflow plugin.


Controlling script flow with simple labels, while, and GoToIf usage

  • Random: This library allows the creation of random numbers and strings according to certain parameters. It proves useful to randomize data in relevant test cases.

The usual recipe

After running the IDE window, you will be presented with a blank project. In most cases, the formula to prepare a test case revolves around three basic steps:

  1. Record an execution via manually running a test case.
  2. Fine-tune the recorded script to make it as generic and robust to change as possible, without compromising its ability to validate test conditions. This is the lengthier stage.
  3. Integrate your new test case in the corresponding suite, adding flow-control if necessary. In certain usages, you will want to limit the execution of a test case block depending on previous results and/or required coverage for a release.

Inevitably, you will have to revisit your script as the tested product evolves. Scope changes like new features might require updates. Similarly, the identification of faults in production might bring the need to expand coverage with new tests.


(The Selenium IDE interface, including extra plugins)

Once a stable pool of tests is consolidated, they are executed considerably faster, especially when repeat runs are required. That does not mean, however, that the test cases will not need to be revised often; in our environment, the sprint cycles mean that new functionality is released every two weeks.

In some (most) cases, such new functionality does not affect older regression test cases, but there are occasions when a major interface change might require tweaks to the current scripts, or even a full rewrite. Every time you refactor a script, you might find new ways to make it more adaptable to future changes and updates.

Tracking variables

One way to make the test cases more robust is to use stored variables instead of hardcoded content as much as possible. You can do this with the Store command, later retrieving content with a $ wrapper for full flexibility.

For example, if you store “bar” as the variable my_string_text1, you can later use it in any command, e.g. a Type command with “foo${ my_string_text1}” as value would result in “foobar” being output anywhere during script execution.

If you installed the Stored-Vars plugin mentioned before, a new tab at the bottom of the interface will allow you to keep track of variables, useful during debug/step execution.

Extending the native commands with JavaScript usage

Se-IDE provides a limited number of native functions out-of-the-box. In case you require something that Se-IDE does not originally do, you can add your own JavaScript code. A simple example would be randomizing a username:


Using this in the ‘Target’ field of a Store command, would store “TestUser” plus a random 0-99 number in the variable entered in the value field. While Se-IDE did not natively allow it, a simple code snipped added the feature.

Another simple example would be selecting one of three random locations for a web form, in that case you could do it by using something like this in the target field:


Locating objects

Web test automation predominantly revolves around GUI objects i.e. various UI controls like pull-downs, input boxes, text fields and so on. These objects can be identified via Name, ID, Link, XPath, CSS, etc. and some might have changing properties during runtime.

Once a script is initially recorded, you might find necessary to adjust object identifiers, as they allow Se-IDE to identify targets for actions during runtime, and the accuracy of this process is vital.

Firebug can help identify objects precisely, something you can confirm with the FIND button in the “Target” area of Selenium IDE. You can use Firebug’s “Inspect” tool, select the element and then click FirePath to see its CSS or XPath identifiers.


(Firebug and FirePath showing the XPath locator for an image)

By default, the Se-IDE frequently generates index-based XPath while recording – this is not the right approach and maintainability becomes an issue, as the likelihood of a script breaking simply because an object is later moved is high. For this reason, it might be beneficial to convert those locators to IDs or CSS.

Se-IDE locators’ work on single HTML references at a time, but often you need to work with a nested HTML structure with frames. Firebug can help analyze the HTML DOM to help you derive the best object identification locator.

Wrapping up

In our next posts, we are going to work on a short tutorial and later create advanced automated test cases using only Se-IDE installed as described, as well as delve deeper into locators, recording and editing, and custom JavaScript usage.

Even though the Se-IDE has a decent amount of functionality, it also has a few limitations, for example, it is restricted to only Firefox and it lacks the ability to scale well. To counteract that, we will show you later how to use the IDE to help write cases for the standalone, external Selenium Server.