In an Agile practice, verification should be fairly light. On the other hand, exploratory testing would be more important to uncover unexpected or possibly unwanted behavior. I think in a very true way a lot of what would be bugs in a waterfall process would become new requirements in an agile process.

I only point out that there are circumstances when it happens. Granted, when this happens there are other problems in the project and in the team that need to be addressed. It is still a fact that a more thorough QA practice can further destabilise the development process and ultimately paralyse delivery.

Your comment also makes it clear that the style of QA applied is important. Automation to test validated behaviour will never lead to this effect. I think this effect is a result of a tougher acceptance (i.e. at a level of details that appears excessive) and exploratory testing on cases that would not be relevant to the user (because it is not a valid business scenario of because it is a rare circumstance easily worked around in practice).

Note that this is very much in the realms of perceptions/communications. It may also mean there is a disconnect between an agile development practice and a waterfall QA practice (with all the quotes and asterisks that apply ).

I agree with the first point that it will take longer to finish a task. When I started my career in software development, I had the naive notion to strive for perfection, both in development and QA. As I get older (and hopefully wiser), I realize that we should strive for “good enough” instead. We should also bear in mind that oftentimes fixing a bug introduces more bugs. The famous story is that of astronauts carrying bulky binders of known bugs when boarding the Space Shuttle because NASA deems the bugs minor enough and does not want to risk introducing more unknowns. For this to work, managers must be able to accurately classify bugs at different levels.

I do not agree with the second point above. My experience has been that, when QA is thorough, developers tend to be more careful in their own testing, to avoid the embarrassment of their stories failing QA. At any rate, if QA’s testing is automated, then I personally would not make much distinction between developers’ unit/integration tests and QA’s. Again, I have seen that developers’ attempt to stay respected among their peers will keep them diligent. Managers should also monitor whether individual developers tend to produce code that often fail QA.

The last point can only be addressed with more experienced managers. Again, the signal should be “quality is important at certain levels”. Someone will have to make a call to decide how bugs are categorized no matter what. How this can be done effectively probably should be addressed in another blog posting.

Second, I do not think it is only about trust. Trust is always a nice to have whatever the work and the process. It is certainly an important part of agile processes but it is not initially given. Collaborative story writing is an element to build trust but also goes beyond that. Everything that makes the process open and transparent helps building trust.

In my mind, being Agile should be like how the UNIX system was first developed by Ken Thompson and Dennis Ritchie. I wonder what UNIX would have become (or if it it would even be as popular) if they had needed to keep “well-written” stories as the code was written. If end-users and developers really share the trust and commitment that Agile requires, not having “well-written” stories should not be an issue.

This begs the question: Do users and developers ever can have that kind of trust and commitment?

I’m very happy with the associations and conclusions you have offered here. They support my own perception of agile practices. What I would like to be able to do is measure the quality and impact of the feedback loops…