Switching to Agile Testing, not as simple as changing your t-shirt

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?

Definitely NOT!
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.
- Self-organize.
- Focus on people.
- Enjoy :)

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?

,

  • http://www.kalistick.com Kalistick

    Nice article I totally agree with. Becoming an “organic part” of the team is one of the most challenging evolutions toward Agile testing. It often create difficulties for both developers and testers to understand eachother, and thus decrease testing performance and let regressions appear. I wrote an article about this understanding difficulties lately. Here is the link if you wish to have a look: http://blog.kalistick.com/Tests/developers-come-from-mars-and-testers-from-venus/

  • Pingback: How to switch to Agile testing « Brian Heys

  • Anonymous

    Liked your article, thanks for the link!
    I think communication is only part of the issue, there is also lack of mutual understanding and respect for the work of the other, and I think even some professional jealousy…
    All of these can be seen as team-culture gaps that need to be mended as part of the process of transitioning into agile; and they should be considered when planning the process to do so.

    Again thanks for sharing your article and your inputs!

    -joel

  • Nathan Bain

    “Enjoy” may be the last principle you put on the list, but it has to be the highest priority in my opinion. If you are enjoying being an agile tester, then you have probably got the other principles 9 right.

  • Anonymous

    You are giving me too much credit, specially since Lisa and Jeanette came up with the list.
    But I will definitely agree with your assumption that if you are enjoying your job as an Agile Tester then you should be doing the other 9 right.Cheers!-joel

  • John Reber

    The best thing about working in an agile environment as a tester is the removal of the traditional ‘down-time’ when testers finish a bout of testing then wait for documentation to slowly come in so they can start writing scripts etc. Agile can be frenetic but that’s what makes it fun and challenging. You will probably learn more about your industry on a 3-6 month agile project then you ever would on a 2 year waterfall project.

  • Anonymous

    Totally agree with your last comment John, you will NEED to learn more about your industry, users, competitors, etc on an agile project because this is part of your task.  For me this is also one of the parts that makes it exciting for a tester, because all of a sudden we are required to look outside our small little lab and interact with the real world out there!

    -joel

  • Peter Callies

    Good post, but I disagree with a couple assumptions in #4.  

    It seems you’re implying that an Agile project isn’t “under control.”  Can you elaborate more on that.

    You also imply that documentation leads to issue and risk mitigation.  I strongly disagree.  One of the main reasons for Agile is to mitigate risk via empirical evidence.  Just thinking and writing about issues often leads to bad assumptions that snowball into big problems later on.  You need to actually prove/disprove these things instead of hypothesizing about them.
    Learning to deal with a lighter process and less documentation is definitely a challenge, but heavier process and more documentation don’t yield the benefits you imply.

  • Anonymous

    Hi Peter,

    I’m not implying that Agile Projects are not under control, I am saying that we testers sometimes use documentation in order to *feel* we have control of the project.  

    By control vs. lack of it I sometimes like to use the analogy of skying vs. running:
    - When you run both your feet are on the ground and you can define very strictly when and how to turn left or right.  You can also fall when you don’t do it properly, but you have a feeling that you can stop immediately if you really want to.
    - When you’re skying (or at least when I am, and I am not really a pro at it), you glide and have control of your path, but the ability to stop or turn *NOW* is something that is less under your immediate control.

    You can say that also when you sky you can turn and stop whenever you want to, but the fact is that the distance given to stop when you are running a 100m sprint is a lot shorter than the one they give when they are doing downhill slopes.

    About documentation for risk mitigation, I will disagree with you.  IF you document correctly and you have a good process to review your documentation, and also if you have stable requirements that will not be changed by your Product Owner 7 times during your 9 month release cycle, then you will find a large number of bugs during your documentation and review process.  The problem is that all 3 assumptions I wrote above seldom happen on real life projects.  This is where Agile helps, because with shorter sprints and by reducing documentation we are able to focus on less formal communication and the empirical detection of issues, but understand what this means, you are saying that instead of having 2 or 3 safety nets (reviews, dry tests and empirical tests) to catch bugs you now depend on one (empirical tests) to catch them. For a tester this is more pressure on his work and so it is something he needs to deal with, even if only on the psychological level.

    I agree that lighter process have advantages, but I also know that a process is not better or worst because of the amount or depth of it’s documentation, as I’ve worked in great projects that were extremely documented, and also on very bad agile projects with light.  Agile development is great but it is also challenging and as error and abuse prone as any other methodology, in the same way as a waterfall project is not bad only for been waterfall in nature…

  • http://www.qainfotech.com/methodology.html Lisa Davidson

    Very nice post. I like the complete coverage and comments on Agile technology and project. It is indeed a good platform to share ideas on Agile testing and other QA Testing methodology.

  • Lisa Davidson

    1.      
    After this wonderful post, may I request you to
    post something on Cloud Testing and its benefits. Look forward to your next
    post.

  • joelmonte

    Nice additions, they are really accurate on Agile Projects (and not too uncommon on many non-agile projects I’ve been a part of).

    Specially the direct communication with development, that even when there is plenty of documentation needs to be present and encouraged as much as possible.

    Thanks for sharing!

    -joel

  • http://www.inerdtia.com/ inerdtia

    And what about tools to manage/store test scenarios? Can anybody relate/share what tools you have been using to manage agile testing?

  • joelmonte

    At PractiTest we use our own QA Management system to manage our Agile Process. Starting form User Stories, all the way to Tasks and Tests.

    We even wrote how to do this on this post where you can read how to easily configure the system to cover your Agile process – http://support.practitest.com/customer/portal/articles/256703-managing-agile-testing-in-practitest

  • Pingback: How to switch to Agile testing | The Naked Tester