Matt Heusser wrote about the question Are testers going away? in a blog entry yesterday. As I started to write a comment on his blog, I noticed that I should selfishly make an own blog entry out of it. So, in case you haven’t read Matt’s entry, go there and read first, maybe.

In fact, I sincerely believe that Weinberg wrote the Quality Software Management series just for this very reason. When looking around, I far too often see managers forgetting about the measurement systems and forgetting about what to do in the light of the pressure to get the product to market. The Craftsmanship movement has been created just for this very reason. Robert Martin raises the point in his QCon talk, that a responsible developer should ask their managers “Do you want quality or crap?” It’s sad to admit that the same seems to hold for most of the testing being done in the companies nowadays.

I wholeheartedly agree that testing is shifting from the quality control business towards quality assistance, as Michael Bolton and James Bach and Cem Kaner, and… point out. And yet, this shift in the jobs is just beginning.

The last decade (or so) of Agile software development has taught myself one thing. Initially Agile methodologists claimed that they will no longer have any need for a tester among their teams. Challenged by these statements testers like Elisabeth Hendrickson, Lisa Crispin, Janet Gregory, James Bach, Jon Bach, Michael Bolton, Matt Heusser, … started to show that this claim was wrong. In fact, in the aforementioned talk from Robert Martin he points out, that while the mantra for a programmer should be that QA should find nothing, they will still find bugs. But instead of thinking about something bad here, this is just a natural thing. To err is human (and to Arr! is pirate).

So, what can we learn from this past decade? What these “pioneers” – I know that I wouldn’t feel myself as a pioneer – show us, is that the role of the tester changes on an Agile team – for good. While you keep to work in cycles on more traditional teams, since there is a back-and-forth with bugs that blur the view on the bugs hidden, working together with pride developers demands for shifting the activities you do. You still do some exploratory testing, you still explore the application, you still apply critical thinking to what your perceive and you still investigate what might possibly go wrong with the product. But you get less rework with this when the program you get is already well unit-tested. A fact that is known for decades past. Of course, this shift in your position as a tester may sound frightful, when you love to punish your programmers, but I hope for the majority in our craft it does not.

Now, what are we going to expect in the future to come? I don’t know, and I would be a rich man, if I knew. But one thing I know for sure: “Once you eliminate your number one problem, number two gets a promotion.” (Gerald M. Weinberg, The Secrets of Consulting, p. 15). So, once the problem of bad code is eliminated, the number two problem will get a promotion. I’m not 100% confident on what the number two problem may be, but I’m confident that we’ll be able to tackle this.

And I hope there are more testers ready for this.