Skip to content Skip to footer

Insight

The rise of test automation and the tools you need to get started

by George Fraser, Lead QA Analyst, 8 June 2016

Read Time: 10 minutes

Test Automation enables project teams to respond rapidly to change while still providing confidence in the quality of the product. In this blog, I will be talking about two test automation tools that are in use at Redweb and how they help us to work more effectively.

Since the move towards Agile development, the role of the Quality Assurance (QA) Analyst has changed to adapt to this different way of working. As Agile development requires more flexibility and the ability to respond to changes in short timeframes, QA Analysts now have to work more efficiently than before.

This is especially true in projects that have multiple sprints, where further functionality needs developing within an existing system. This, paired with the need to produce the same level of quality from an Agile project as expected from a traditional Waterfall one – which has pre-defined, fixed deliverables, means that the role of the QA Analyst is more valuable than ever. As the number of changes and the outputs from development teams increases, so does the risk of regression in a system.

QA Analysts need to be able handle the increase in risks and the fast pace in which things can change; the best way that they can do this is through test automation tools. Test automation tools are not new, but they are becoming more widely adopted within the industry.

Should a project require the release of a minimum viable product or involve multiple sprints working in the same area(s) of the system, there is always the chance that changes made later on will affect, or even break, code written at an earlier stage. Testing for regression can form a large part of the testing effort, often involving running the same tests multiple times throughout the course of a project. This is neither cost nor time effective and is what test automation tools are designed to combat.

The QA Analysts in my team at Redweb are currently using a couple of test automation tools. Both of these tools are free to use and form the bulk of our automation effort.

Selenium is one of the most popular and widely adopted automation frameworks available – it is open source, easy to use and, depending on the choice of version, supports a range of programming languages out of the box.

There are two, very different, versions of the Selenium framework:

Selenium IDE (Integrated Development Environment) is a lightweight plug-in for the Firefox browser. We like using it for the following reasons:

  • It enables the user to record a set of steps for playback later. The user clicks around the website in the web browser and Selenium IDE records the journey taken.
  • The user is able to make assertions on a page. These assertions are key to the test automation process. They form the ‘expected results’ of the test. For example, a user has navigated to a page on a website and they want to check that the title text is correct and the main imagery has loaded. Using Selenium IDE, these elements can be Asserted. Selenium will check that these elements exist on the page, that they contain the correct values, and that they are in the right place.
  • Any failures are flagged red for the tester to review.

A screenshot of a passed test in Selenium IDE

Although the Selenium IDE is very useful, the other version of the Selenium framework, Selenium WebDriver, can be favoured where the needs of the tester become more advanced. The differences in functionality include the following:

  • Tests in Selenium WebDriver are not as easy to create as in IDE. They need writing in code as opposed to recording; however, there is a handy export feature in Selenium IDE that allows the user to export the scripts they have recorded into Selenium WebDriver.
  • One of the main advantages of using the WebDriver over IDE is the ability to create tests in a wider variety of languages; WebDriver allows the user to create tests in Java, C#, Ruby, Python, and PHP, amongst others.
  • The WebDriver solution also allows the use of ‘Headless’ browsers. ‘Headless’ browsers are browsers that do not run a GUI (Graphical User Interface). This means that tests can run much quicker, decreasing the time needed to run through an entire suite of tests.
  • One of the biggest advantage of Selenium WebDriver is the ability to integrate with development and build processes. By using WebDriver, a developer can take a suite of tests created by QA Analysts and make them part of the overall solution, meaning every time the solution is built these tests can be set to automatically run. This not only saves QA Analysts a lot of repetitive manual testing, but also provides the whole development team and project stakeholders with confidence that a change has not broken key system functionality and that any major errors will be flagged quickly before progressing any further.

The next tool to examine is Wraith, an open source tool developed by the BBC, which helps to identify visual regression. We use Wraith for our projects for the following reasons:

  • It works by taking two sets of screenshots, overlaying them and highlighting the differences. Wraith allows users to specify which URLs they need screenshotted.
  • Wraith takes screenshots of a site before making a change and another set of screenshots afterwards, comparing them immediately. The tool highlight the differences meaning testers no longer have to play ‘spot the difference’!
  • The tester can set a variety of browser widths for the screenshots meaning we can test responsive designs as well, all within the same run of tests.

A screenshot of a report from Wraith showing how web pages of BBC News appear at 320 pixels and 768 pixels

It is worth mentioning that although Wraith and Selenium save on testing time in the long-term, they do take some set up time. Selenium requires investment in creating test scripts, scripts that nearly always require maintenance time. Wraith requires installation through the command line and installation of a number of third party dependencies. A configuration file needs authoring with the URLs for the pages we want to screenshot, along with the necessary screen dimensions.

In conclusion, it is nearly always worth the time to get set up with automation tools if a project’s delivery is due over multiple sprints or iterations, or if the project is long-term. Then, automation tools can quickly become invaluable to the quality and efficiency of a project.

The next step for the QA team at Redweb is to develop deeper integration of the tools with our build and deployment processes from the start of a project. They enable QA Analysts to establish the success or failure of a deployment almost immediately and provide the project team, project stakeholders, and clients with the confidence that we can achieve a high level of coverage with only a few clicks.

Sign up for our newsletter

Be the first to get insights from the digital world and the latest Redweb updates.

Thank you

By entering my details, I agree to the use and storage of my data as described in Redweb’s privacy policy.