In addition to all my other tasks in PractiTest, I am a tester working and consulting on a number of Agile projects. In total I’ve been in testing for over 15 years and doing agile testing for close to 5 years.
Here’s a fact some people tend to overlook, just like any other profession, to become an expert on a specific field of testing you need to work hard and develop the skills required for that specific type of testing. And so I know some very impressive testers that are experts in the field of Load Testing, I also have a number of colleagues who I define as Automation Experts (having the strange ability of been good testers and good developers at the same time), I also know some pretty impressive Exploratory Testers, as well as a number of Security Testers, Usability Testers, etc. Each one of these sub-especializations comes with their own challenges, added value, tasks, etc.
Agile Testing is also a sub-especialization of testing, that comes with some pretty singular challenges, and requires specific skills that a tester needs to develop in order to succeed in his job. Without underestimating non-agile testing, I find that testing on agile projects can be a lot more challenging and demanding than been part of, let’s say, a Waterfall testing team.
In fact so demanding, that lately I have seen a number of testers that were very valuable and effective working on non-agile projects walking-out or been laied-off from teams working on agile organizations, because they just didn’t have the skills required to make the transition into Agile Testing.
What’s so demanding about Agile Testing?
There are a number of things that make agile testing challenging. I think the main ones (or at least the ones I see more people stumbling and failing) are: becoming an organic part of a development team, finding yourself as the “lone tester” in charge, the “crazy” pace of Agile development, and the need to work with a slim process & documentation and the risks involved with this.
1. Becoming an organic part of a development team is demanding because of the intrinsic rivalry that usually surounds the relationship between developers and testers in non-agile teams. Even if we all have the same objective and target, each of us approaches their jobs in a different (and sometimes opposing) angles.
Agile testers and developers need to learn how to work together in one team. When you are part of the same organic team it’s not enough to have the same goals and objectives on the “MACRO level”, and we need to find the way coordinate our tasks and jobs in the “MICRO level” as well.
This can be frustrating for both developers and testers, and somehow (maybe because of the cultural baggage that we are still carrying from pre-agile times) testers always feel they will need to concede to developers even when they don’t agree with them.
2. Finding yourself as the “lone tester” in charge is challenging because all of a sudden you need to work alone, calling the shots and taking the risks in front of your programming peers.
It may sound strange, but there is a big advantage that comes from working within the “protection and support” of a group of testers that, when push comes to shove, will stand next to you and defend your “testing-based” approach. For someone who has not been in a leadership position (as a team lead or manager) this can be very intimidating.
This issue is specially acute if the Agile Team Lead and the Scrum Master also lack the experience and understanding to know that they need to provide backing and support to their testers…
3. The crazy pace of agile development is hard to all the team, but it is specially challenging for testers that continue doing a big part of their testing tasks towards the end of the process (even if we work on short sprints).
This issue becomes even more acute because when you work on an agile team, towards the end of the sprint you are supposed not only to run your most critical tests but also to “employ” your fellow developers in order to get some help in the testing tasks, and we all know that managing developers to do testing tasks is not easy (not even in the remote possibility that they really want to help…)
4. Working with a slim process & documentation and the risks involved is the fourth challenge for testers transitioning into Agile.
Whether we like to accept it or not, many of us use process as a way of controlling our projects. When the project is under control we have a better chance of discovering and managing most of its risks.
The same goes for documentation, when people need to document their work (and when they do it correctly!) they tend to find more issues and discover more risks earlier in the process.
Because agile projects work with slimmer processes and very limited documentation, then the responsibility of the tester to find and manage the risks of the project becomes more important but at the same time more challenging, since he needs to find alternative mechanisms to detected these risks and control them with the rest of the team.
What can you do about it? Should you stay away from Agile Testing?
Many people, including myself, find agile testing to be extremely fun and gratifying. It provides us with challenges that expand over the methodological, process and technical realms; and allow us to influence the development process even more than working in more traditional “V-Model” processes.
The best thing to do if you want to transition into an Agile team is to make sure you understand what you are getting into. Talk to agile testers and if possible go and see how they work. Make sure you can see yourself working and enjoying the “organized chaos” that comes with agile projects.
Once you decide Agile Testing is what you want to do, work on developing your agile testing skill. How? You can “jump into the water” and start working on agile projects, but take it one step at a time.
Another thing you can do is study. Start by reading some good books, like Agile Testing (by Lisa Crisping and Janet Gregory) where they explain how agile testing projects work, and how a tester can succeed on them.
I specially like their 10 principles for agile testers:
– Provide continuous feedback.
– Deliver value to the customer.
– Enable face to face communication.
– Have courage.
– Keep it simple.
– Practice continuous improvement.
– Respond to change.
– Focus on people.
You can also find countless blogs and articles on the subject by simply googling “Agile Testing”.
What say you?
Do you have something to share from your transition into agile?
Please come and share it!
Is your experience of transitioning into agile different?
What tips do you have?