Automated testing in Agile Projects

We have previously discussed where the differences in the tester’s role lie between projects operating in a traditional model and those working in an agile manner. So far we’ve mentioned the general differences between the two as well as the differences in test documentation and requirements management.

To a certain extent, the same differences exist when it comes to the subject of automated testing. In the agile way of doing this, the goal is that what the team agrees to do in a sprint is delivered with high quality when the sprint is completed. This means that the sprint contains activities for requirements design, development and testing. Everything should be completed before the team starts the next sprint.

Sprints are usually about a month long, but can also be shorter. The next sprint builds on what has been done before and therefore the amount of regression testing quickly becomes very extensive.

The intent of regression testing is to ensure that a change, such as a bugfix, did not introduce new faults.

The word regression means that the system can regress, meaning that it could be worse than it was before the change. Sometimes we therefore refer to this phenomenon as “improvement deterioration” or “worsification” or even “unprovement”, since while trying to improve the system we unintentionally made it worse than before.

To be able to regression test all existing functionality, tests are often automated by the developers. Writing automated test cases is not technically complicated. What is complicated is the master test design, which testers have profound knowledge about. You therefore have an important role to play when transferring testing knowledge to developers. As a tester, you also need to understand more of the technology used to be able to help with automation.

In return, when you work as a tester in an agile project you often get help by the developers. The developers write the automated tests, generating testing data, setting up test environments and anything else that makes the team deliver on time. Suddenly you as a tester are an important and natural part of the team because you have knowledge and experience to perform these tasks. When the developers and you share the same definition of ‘done’ no one will think that everything is done just because the coding is finished. Furthermore, you will probably even get a better understanding of the problems that developers face daily.

If you have test automation in place, you as a tester will be able to focus on the manual tests that are needed for the newly developed functionality through exploratory testing, all while learning more about different areas you wouldn’t know of in the traditional approach, and being part of a cohesive and efficient team.