I noticed your talk on testing in agile teams in a conference later this year. The ideas you have proposed are mainstream among agile developers. I also think the overall approach is negligent. It’s particularly disappointing since I greatly admire your contributions to rethinking certain aspects of agile.
The most disturbing aspect of the talk is the complete ignorance of testing as followed by the group of testers who are mostly part of the Association for Software Testing or those who follow context driven testing. It’s also disappointing that the main thrust of your talk is about not following certain testing practices, which good testers have not been advocating for more than two decades (such as a phased approach to testing). I would recommend that you spend some time with good testers to understand their point of view and then develop an opinion for or against. I would also recommend validating with those testers whether your understanding is accurate.
Manufacturing vs. design
I strongly recommend against using manufacturing terms or concepts, like inspection, related to testing. It is widely accepted that software development is like design. Concepts like inspection are very closely tied to physical artifacts and not to abstract design. These concepts have never been part of good testing.
In your abstract you position ‘building quality in’ in opposition to testing. However, these activities are not exclusive. You can do both together. It is illogical to present these as a choice. In many cases when presenting concepts as a (false) choice, there is a lack of knowledge about the alternative which is being rejected.
Agile development and your talk has some very good ideas about testing and quality. However, it doesn’t diminish their value by not showing that they are superior than other practices. You don’t have to pit one idea against another. This also prevents you from understanding the other point of view, in this case, testing.
Building quality in as opposed to testing
One of the ideas you propose is ‘building quality in’ as opposed to testing. I think this concept is not ‘either-or’. Building quality in does not eliminate testing. More importantly it does not reduce the need to understand testing. If building quality in reduces the effort of testing, and I believe it does, that is more than welcome.
Preventing defects vs. fixing them
This is another concept which is not either-or and is very similar to the previous. What is odd about this idea is that it seems contrary to very important agile concepts such as ‘fail fast’. In the context of agile development, I think it is accepted that you build small thin-slices of software, in order to get feedback. You can think of testing as providing that feedback. The only difference is that instead of depending on the customer to provide feedback, you take efforts to evaluate your deliverable yourself. Note again that getting customer feedback is not either-or with taking efforts yourself.
Agile has radically changed software development. The complete ignorance of testing, as practiced by the Association for Software Testing, is puzzling. Agile provides a great platform for good testers. The testing community has also embraced agile and good testers play more of a coaching role in self-organizing teams. If agile developers took some efforts to understand testing, agile development would greatly benefit.
(Note: I am not affiliated with the Association of Software Testing.)
Originally published at www.softwaretestingclub.com.