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. John Stevenson explains why there appears to be some fear and a little distrust of agile among some testers, then offers suggestions for dealing with their confusion.
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 purpose of a tester in agile environments is about getting things done rather than roles. As a tester, you should try to act as a service to the project and ask yourself, “What can I do that is best for the team or for the project?”
There are many other roles a tester carries out during testing, such as a coach or mentor, a service provider, a sage, a confidant, and a person who is willing to listen as well as challenge others for the benefit of the team.