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.