Automated tests | Gestión de proyectos ágiles

(Sorry, this is a technical post about software testing, but don’t worry, you can find here some of my non-technical blog posts)

A few years ago we used Selenium IDE in a web application project just to check the functionalities developed at that sprint were working as expected but there were some problems with that. I try to sum up them here:

Selenium IDE works only with Mozilla Firefox web browser. That was a problem when you did need to test another browser or your web app worked only in MS Internet Explorer.
Tests and tests suites used to become red frequently. Firefox updates (on security mainly) made script commands deprecated easily so it was needed to search for a replacement, when available, or to find a workaround (after a few hours in Stackoverflow). To keep them working in order was costly (and time consuming).
There was some kind of a mess with script commands: type or typeKeys, click or clickAt, mouseAt or mouseDown. You never knew.

There were also some advantages, of course, like the way the user actions could be recorded by the IDE. You just had to click somewhere, move the mouse or type something that your movements were recorded by the IDE as script commands. It was needed to adapt or fix them after recording it but it used to made things easier.

These days I have been playing around with Selenium WebDriver. It doesn’t need to inject javascrit code into the web browser and you can use your favourite programming language to write the tests.

I have written a couple of tests to check one of my web applications just to show you some of its main features and how Selenium WebDriver can work on Chrome. At the end of this post you can find a video showing how these tests work.

This first test is a kind of smoke test just to check that the application is working properly and shows the main page when it is requested:

Below you can find how to get the driver variable for Chrome. Using it you can have access to all WebDriver commands. It is written inside the jUnit @Before annotation so it is going to be executed before any other test run. At the @After method there will be a driver.quit(); sentence.

This last test actually checks that 10 questions are asked at each attempt (no more, no less), chooses randomly one of the multiple choice options and ensures that there is a results page at the end.

This is the Selenium/JUnit tests video recording:

You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).

Agile 101 – Practical Project Management

References:

You can find here how to set up Selenium WebDriver in Eclipse.
Selenium WebDriver, Selenium RD comparison.
Code of this sample class can be found as a GitHub Gist.

Last Thursday I had the honor of giving a presentation on Phase 2 of the Canary Islands Waste Information System (GUIRRE) at the Fourth Conference on Sustainability inside the activities for the World Environment Day.

GUIRRE is a very special project for me for several reasons: It was the first time we run a project using continuous integration (Jenkins) and automated tests using Selenium IDE.

At the beginning of the project, before starting to program, we defined a section called ‘How to test it’ for every feature we had to develop. We recorded tests with Selenium, following the steps of the ‘How to test it’ section. Those tests helped to show that the new feature worked properly. If we found a bug, we recorded also a test to reproduce it. When the test became green, we had fixed it.

Every two weeks, we recorded all tests of the current Sprint on a Selenium ‘suite’. Every night, the continuous integration server, Jenkins, ran the suite and all suites from previous Sprints and reported if there had been mistakes. If the previous morning someone had modified a piece of code affecting a functionality developed some months ago, Jenkins showed us some dark clouds.

The other reason GUIRRE is a dear project to me is because we managed to finish under budget (yes, those projects exist) despite we fully assumed the cost of learning Jenkins and Selenium, and that the budget was very adjusted. Quite a challenge.

I leave below a few pictures of the event and a link to the paper I presented. Hope you find it of interest.

Archivos por Etiqueta: Automated tests

Functional tests with Selenium WebDriver

IV Conference on Sustainability

Buscar

Suscríbete