The Role of Testers in an Agile Environment


There are many diverse ideas about what being a tester means in agile development environments. This leads to confusion between how agile testers and agile QA “fit” into agile teams and what the QA tester responsibilities are. John Stevenson explains why there appears to be some fear and a little distrust of agile environments among some testers, then offers suggestions for dealing with their confusion.

At my day job we’ve been driving toward a more agile way to develop software. Just like with any other change in work style, there is some confusion and, for a few, a little bit of fear. People are being asked to step out of their comfort zones and embrace a constantly changing, dynamic way of working. And—dare I say it—testing may be the most disrupted of the software roles on agile projects.

What do we think the role of a tester is? Can we even agree?

There are many diverse ideas about what being a tester means in agile development environments. This leads to confusion between how agile testers “fit” into development teams and what their role is.

In this article, I will start by looking at my experiences to explain why there appears to be some fear and a little distrust of agile among some testers, then offer suggestions that may be of use to testers for dealing with their confusion.

Confusion in the Literature

One of the few things people tend to agree on is that to deliver working software quickly, teams need automation in place which leads to the “testers must code” discussion. Experts like Elizabeth HendricksonRob Lambert, and Michael Larsen have suggested that coding is the next logical step for testing, but there is no overall consensus on that. James Bach’s comment to Rob Lambert’s article suggests there is more for testers to do than only learning to code:

. . . [T]elling testers that they need to learn to code will discourage interesting thinkers from becoming testers. We can’t assume that people who like to program are just like other people in every important way.

Tester as an Agile Team Member

Historically, testing activities have happened at the end of the development (coding) effort because a tester’s responsibilities included proving the requirements were met, ensuring the software worked, and finding bugs in the mostly finished product.

The Agile Manifesto flips around titles and roles and says to focus on individuals and interactions over processes and tools.

This means that as testers, there is a need to work as members of the team and to engage with others within the team, regardless of titles. If you see a task that needs doing and you have the skills to do that task, then just do it.

Agile processes mean testers are part of the delivery team and should try to be involved from the beginning of the project. Testers should have the ability to “switch hats” and be involved to support and assist the team.

The following are only a few examples of the vast number of roles you could be taking on.


User Comments

Clifford Berg's picture

There is so much confusion in the industry about what testers should do in agile projects. Part of the problem is that the most widely used framework - Scrum - says almost nothing about it. This article helps to clear some things up.
Experienced agilists know that things like test plans are needed. Indeed there has lately been a series of discusison threads on this in various LinkedIn agile groups, and the overwhelming consensus is that (1) a test plan is needed, (2) it should be concise and allowed to evolve (not big-plan-up-front), and it should focus on test strategies - not detailed test procedures: e.g., it should say how functional testing will be done (unit, acceptance, integration), how performance and stress testing will be done, how security testing will be done, etc.
And then there is the issue of who is a tester. As John points out, anyone on a team can be a tester. In an continuous delivery setting, a tester is usually a test programmer. And it is highly technical. Non-techies can write cucumber scripts as John explains, but the implementation of those is pure code. BTW, the Java version of cucumber is not ready for prime time, so if you are a Java shop use JBehave - it works in a very similar way to cucumber.

But I personally feel that testing needs structure. Agile teams tend to encourage ad-hoc: try to include yourself in discussions, etc. But for testing, you need to dot the i's. You _need_ to be in certain discussions. Things _need_ to be done a certain way, or the process is compromised: e.g., the person who codes a story should never, ever be the person who writes the acceptance test code for a story.

Finally, the concept of test coverage is essential for continuous delivery and enterprise risk management. The old waterfall process relied on gates to make sure everything got checked: continuous delivery relies on testing. For that to work, there needs to be a way to measure the completeness of the tests. That is what test coverage is, and the concept applies not only to functional tests, but also to every category of risk: security, reliability, maintainability, etc. If there is an area that the organization cares about, there should be tests for that area, and their coverage should be assessed. And putting all that together usually requires someone who knows a-lot about those areas. It also requires some independent oversight.

None of that is mentioned by Scrum, but that does not mean it is not important. If you want to get to continuous delivery of reliable and secure systems, these things are necessary.


November 12, 2014 - 9:48am
Giezelle White's picture

Good read.  Really emphasizes how we're undervaluing testing and how we can begin to improve that outlook.  I'm looking forward to expanding on these ideas and setting up concrete plans to incorporate them into my teams' methodologies.

May 6, 2015 - 12:20pm

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.