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 Hendrickson, Rob 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.