About Agile Testing and Nonsense
I was writing down a new post about agile performance testing (which is one of my favorite topics for a while – last version was presented at the Performance and Capacity conference by CMG) when I stumbled upon Agile Testing Days 2013: Agile Testing is nonsense, because Agile is testing… by Andrea Tomasini.
It upset me enough that I decided to write about it first. No, I don’t agree. Moreover, I believe that it is harmful if read it literally (probably the author brought it to that level to attract attention and stress his points – mostly very good points – but I just sharing thought that came to my mind when I read it).
While I agree with almost everything that was said there – I don’t agree with where it is going. “Testing as an attitude”. “Testing as an approach”. “Testing as a practice”. “Testing is a Team responsibility”. True in certain contexts. Yes, testing is changing and redistributing with new software development methodologies and agile approaches – and it looks like we are just starting to realize how it should be. But I am pretty sure that saying “Testing is a Team responsibility”, while true in some sense and a valid point, is not the answer.
The Agile Manifesto doesn’t saying anything about organization of development teams, details of software implementation, or the length of meeting – and wisely so. It formulates just basic principles. Perhaps we may say that the Agile Manifesto states that life is too complex for rigid processes – and we need to be flexible and get as much feedback as possible (in a way, indeed, test).
By saying that “Testing is a Team responsibility” and that we don’t need separate testing at all is just pure idealistic. Most original agile software development methodologies mostly ignored testing as a separate activity, I guess, from similar considerations. It may work in simple cases / small projects – well, there were times when there were no testers and some software was developed too. IT shops without testers are not too hard to find. Not that this view is something especially new.
I believe that it ignores at least two very important considerations: specialization and priorities (in addition to the bitter truth that the world is not ideal). You can’t be equally proficient in all activities and you can’t have equal priority for everything (and in practice functionality gets priority over quality or performance – which has some ground because you can’t have quality or performance without functionality). But as the system get larger people tend to concentrate on the work they are doing and you’d better to get somebody to care about quality, testing, or performance of the whole system – otherwise something may be lost in a gap even with everyone’s best efforts (not that it will be a guarantee – just some alleviation of risks). What are optimal specializations / organizations is open for debate (as always was), but saying that just everybody should care is, unfortunately, not the answer. Not to mention that saying that everybody should do something assumes that there are no special skills that may require people to concentrate on (beyond basic skills that everybody can master in addition to their main line of work) – that is idealistic by itself and somewhat derogatory to the people who specialize in these areas.
Just when I was struggling with the best way to say the above, I stumble upon a great post TDD is dead. Long live testing. by David Heinemeier Hansson, which, in my opinion, address a similar issue providing a much more elaborated answer from a somewhat different angle.
