Note that this post is part of a series where I am ‘live blogging’ my way through the ministry of testing’s 30 days of Agile Testing challenge.
Ok, in yesterday’s post most of the work for me was deferred as I have an entire book to read (I’m making good progress on it and should have insights to share). For today the challenge is to write down in some way what I think Agile testing is. I actually found this very difficult to do, because the short answer is that Agile testing is just testing and to define what testing is, is not an easy job. But I’ll give it my best shot.
What is testing?
Before considering what Agile testing is, I want to first take the more general question of what is testing? Obviously the answer to that is going to vary from person to person, and for me testing is not something that can be encapsulated into one succinct sentence. I think there are a few different aspects of testing we need to consider:
What is the purpose of testing?
Why do we test? That question has helped me define what I think testing is. Why do I test – what is it that my company is paying me for? What value do I bring to the team and to the company as a whole? I think the perception is that we have hired testers so that we can reduce the risk of releasing poor quality products. In that way you could think of the role of the tester as helping teams ship better quality products. One definition I really like is Brent Jensen’s view that a tester’s job is to accelerate the achievement of shippable quality. If I was going to try and define testing in one sentence that would probably be it. We do whatever it takes to help get the product to a shippable level of quality as quickly as possible.
What does a tester do?
But what is involved in doing that? What kind of things does a tester actually do? Well I don’t know about you, but I do many many different things. I write automated tests. I do exploratory testing. I set up virtual machines so I can run automation. I put together build scripts. I work with developers to identify the testing they need to do on their changes. I debug failing regression tests. I file bugs. Sometimes I even fix bugs. I push developers for a better understanding of the product. I question things. I ask why? I spend time thinking about how to improve the way we work. I teach and coach others. I propose changes to our processes. In short, I do anything I can that I believe will help us release good quality code more quickly.
What distinguishes Agile testing for other forms of testing?
So is that agile testing? Is there anything that would be different in the above description if we were add the descriptor ‘agile’ in front of it? Fundamentally I don’t think so. It is true that the emphasis on the kinds of things you do in your day to day work will change if you were working in an agile context, but that will also change as you move between two departments in the same company. At the end of the day you’ll be doing whatever it takes to get to shippable quality more quickly. The day to day work that you end up doing will look different and have a different shape to it, but that is because helping achieve shippable quality is a context dependent activity. This is exactly why it is so hard to define what a tester is and does. We do what it takes to improve things in the context we are in. Will that look different in an agile context as compared to a more waterfall approach? Yes of course! But at the same time the fundamentals of what makes up good testing will stay the same.
Conclusion
So I guess to conclude this, to me agile testing is just testing. The particular details of what a team needs in order to get to shippable quality more quickly will vary from team to team and process to process, but the core work of identifying quality risks and quality blockers will remain the same. A good tester will do things differently in an agile context than in some other context, but that is because a good tester will be about doing what it takes to get done what needs to be done.
offbeattesting 
1 Comment