QA >> Testing

John Overbaugh discussed the proper role of the QA team last week:

In a recent thread on the Yahoo Agile Testing Group (about continuous release), I noticed more than one poster saying something like "I tell management about an issue, and let them decide." This reactive approach to QA has been a pet-peeve of mine. It smacks of cop-out to me, and I've seen it develop into a victim mentality among many testers—myself included.

He went on to explain some of the other (non-testing) responsibilities of an effective QA organiztion. After having read John's post, I'd like to clarify something I wrote earlier:

Your job is find bugs, report them, and make sure that the managers who run the project understand your bugs. It's their job to decide which ones get fixed, and which get deferred. As long as they understood your bug and its implications, it's their call whether to defer. Your job is done at that point.

In context, I was only talking about maintaining a professional attitude when a bug of yours gets deferred. But after reading John's piece, I became concerned that someone would get the wrong impression from reading my post. So to be clear, I agree with John's thesis:

Testing by itself is an ineffective Quality Assurance strategy.

QA is much more than testing. Or at least it should be.