Agile Thinking instead of Agile Testing

We’ve been working on the 3rd edition of the Hebrew Testing Magazine “ThinkTesting“, going down to printing in the next day or two.  This edition’s theme is Agile Testing and so I’ve been reviewing and even writing some articles about the subject.

One of the articles I read includes a phrase that got stuck in my head, translating it freely to English it reads something like “If we look closely into the Agile Principles we can see that they are improvements made to some of the existing development methods with the use of experience and common sense…

At the beginning I was not sure if I can agree with the statement, and then I decided to narrow my focus and look only into the testing aspects of the Agile organizations I know; can Agile testing be (basically) improvements made to the regular testing methodologies by applying the use of experience and common sense?

Is there such a thing as Agile Testing?

I’m not sure… is there?
Lately I think there really isn’t.

Is there really something you do as an Agile Tester that you couldn’t do as a “Regular or Traditional” Tester?  The answer, at least for me, is a definite NO.

Why wouldn’t I, as any kind of tester, be involved in the planning and scheduling stages for the project that is going to be developed by my programming and testing team?  Do I need to call it Planning Poker in order to take part of the process? NO.

Why can’t I as a tester on a V-Model team (if there is such a thing) work with the developers and help them test their features before they  are delivered to me for functional or integration testing?  Do I need to call it pair-programming or Agile Testing in order to make this collaboration happen? NO.

Should you as a tester (in any type of development team!) not work towards having in place the automation infrastructure that will allow your developers to test their changes constantly (CI) or institute a working methodology where Quality is the Responsibility of the Whole Team and not only of the testers at the end of process?  OF COURSE YOU SHOULD!

So in short there is nothing directly related to testing that should apply only to Agile Teams.

Agile Thinking instead of Agile Testing

Still, it would be naive to say that testers in Agile Teams don’t work differently than testers in non-agile teams. But I am starting to realize that this is mostly due to a change in mindset and not due to a change in the job description.

Agile teams simply think differently than non-agile teams.

For a start, my experience is that agile teams are more testing-conscious.  This means that programmers understand the real value of testing and so are more willing to do it than their non-agile colleagues.  Granted, most agile programmers will only go as far as extending their unit-testing coverage or maybe creating some additional functional tests using Cucumber or Selenium, but even this is great step forward.

Agile teams are also less hierarchical, and so developers are able to see testers as their peers, as colleagues who can give them feedback and with whom they can consult on professional issues (and not only as great palls to go out to lunch or for a beer once in a while, which is also good BTW!).

This last point is not trivial, the (hierarchical) differentiation between programmers and testers in traditional development teams is one of the biggest obstacles for a tester who wants to take a more active role in the development process.  This means that a tester in a traditional team will have a harder time been heard, but it doesn’t mean she shouldn’t raise her voice in order to voice her thoughts!  It’s a matter of initially trying harder to get noticed and making sure that whenever you do this the feedback you provide is intelligent and productive.

Lastly, a tester in a traditional team should not “be afraid” to take a more central role in the design of his application and the planning of his project.  Not only are we a part of the team who will be doing the job, but as testers we hold the central role of been the customer advocates within our teams.  The problem is that usually, due to the nature of traditional projects the most intensive part of the testing for project X happens almost in parallel to the most intensive part of the planning for project X+1.  The solution to this is only a matter of making it a priority to be part of the design and planning processes, and committing the time when it is useful.

So in the end, the way we want to work is basically up to us, you don’t need to be on an agile testing team to use an Agile Thinking mindset.

,

  • http://www.practitest.com Joel Montvelisky

    I was talking to with PractiTest user about that the other day. It was in the context of creating a “requirement tree” for the product he already had and how that would take some time to do; that’s where I asked the simple question “why do you need to document the requirements for the features you already created, tested and released?”

    In the end he agreed with me that he really needed to organize only the new requirements, and maybe a tree was not the best way to categorize the information after all…

    Your point is a big one, documentation can serve to cover your back (some people use it to cover other parts of their bodies…) but you should strive to use as little as possible and in my mind only to organize your work.

    Trust, communications, and proactive visibility are a better way to work.

    Cheers!

    -joel

  • http://twitter.com/TestSheepNZ TestSheepNZ

    Nice article, and yeah as a kind of entrenched pragmatic V-model tester, I've felt the same coming and learning Agile.

    I think Agile though can allow us to go forward taking on the best practises. I know one thing I'm very aware of doing is using documentation as a crutch and a safety net. I'm very aware of covering my back using a paper trail – Agile wise it's about giving some of that up, trying to develop trust over cast iron paperwork.

  • http://profiles.google.com/shillu13 Shilpa Vnky **

    Nice post. I like agile thinking. Its really all about changing the mind set. Here is another piece I wrote in the same lines. http://solutions.wolterskluwer

  • joelmonte

    Fully agree, I guess many of us have used paper-work as a means of covering our backs (or other parts of our body for that case…) and I guess that on this point Agile is more about accountability and communication.

    One thing I've also noticed about Agile is that there are no real “Best Practices”… I've seen at least 10 different groups (4 of them within the same company) where each of them works Agile in their own ways. It is pretty amazing to grasp that each of them works agile while non of them really work the same, and I guess this is because Agile is more about adapting to YOUR reality than following the teachings of Guru A or B.

    Maybe this is a topic for a further blog…

    -joel

  • joelmonte

    I liked your post, specially where you say that you don't need to throw away everything you've been doing…

    Agile should not be an excuse to start over again, do so if you need to, but thinking that “magically adopting agile” will solve issues in your product, your workforce or your company culture issues is only an excuse that will take you no-where.

    -joel

  • Pingback: Hot Software and Performance Testing Links – Week of March 28th | Fred Beringer

  • Pingback: Agile Wave: Blogs: Pick of the Week beginning 28 Mar 2011 | Agile Development