Why automate testing?

Are you really sure that only putting testers in the same room as others team members, let you deliver free-bugs & high-quality software?

In the previous post, I wrote about how to bring testers in the war room, with the other team members, identifying a possible agile testing process.

What I tried to describe was a raw hypothesis of what testers should do to cope with an agile enviroment: collaborating with developers and ProductOwner, writing test scenarios and test cases, writing automation tests and executing them, as well as performing exploratory and performance testing.

The scope of this post, actually, is to convince the ones of you not yet convinced, that it’s time to start automating tests, by telling a “nice” story.

Firstly, I would suggest the book “Agile Testing: a practical guide for testers and agile teams” written by Lisa Crispin and Janet Gregory. Several of the ideas and suggestions I gathered about agile testing, actually come from such a book.

Why Automate?

When developing a software, the time inexorably passes and, the application being developed, becomes bigger and bigger, and complexity increases; it will soon take too long to have it completely manually tested.

A condition like that, is primarily responsible of three common drawbacks:

team velocity decreases because developers start to help testers in their testing activities, instead of develop
or/and costs increases, because more testers are put into the team
or/and quality decreases because of the user stories start to be delivered not fully tested, due to few time and too much things to do

A real nightmare, isn’t it?!

What usually happens in a scenario like that, actually, is that testers start to struggle because of the few time available. They inform of such a situation the whole team during the daily meeting.

The ScrumMaster, in order to promote team self-organization, suggests that developers could help testers in executing manually testing, to solve that temporary problem. This choice drives the whole team to deliver less stories, respect to what initially committed, and a sensible decrease of the velocity starts to be detected.

The ProductOwner is daily informed about the situation, he starts to be worried.

During the next retrospective the team reflects about the problem, concludes that is not a temporary situation, hence decides to ask for new testers.

New testers arrive and it happens that, according to the brooks’s law, it takes more time that estimated to have them completely productive because they have to learn and practice and often pairing with others testers. At the next demo the team presents again even less stories respect to what was decided. The ProductOwner continues to be worried.

The ProductOwner then starts to push the team in having more stories released, asking and obtaining to avoid some quality checks and having less testing.

Software quality starts to decrease and this trend is showed by looking at the quality data gathered at the end of each sprint: Unit Test Coverage, Test passed/failed, broken builds, software quality metrics.

The technical debt increases, daily, and the ProductOwner decides to bring the problem to the management, asking for a refactoring sprint, that actually further delays the final delivery.

What about start automating tests?

There are many tools available and most of them are open source tools, which cover all of the following categories: