It is with some apprehension that I launch myself upon a discussion of product quality and QA testing. While product quality is promoted by Marketing and management, people rarely want to see and touch the distasteful details of the QA testing that helps improve software quality.

I suppose an outstanding quality effort flows like a stream, steadily and smoothly, out to an ocean of customers. Then there’s the situation for the rest of us.

Much of the struggle with QA testing in the software industry probably stems from the mistaken belief that, in an ideal situation, testing would hardly be necessary. That by finding the right magic formula of programming, such as the double-helix cross-pollinated self-actualized awesome programming method, there would be virtually no bugs in the code and no need for testing. This belief is a distortion of the quality dictum that better work upstream results in fewer defects downstream.

I know there are software development organizations that achieve truly impressive levels of defect-free output. Hats off to them. I, on the other hand, have found it helpful to understand some of the difficulty that occurs naturally in the effort to improve product quality. Some quality events (some would call them “problems”) happen very naturally.

I compare the creation of software, and QA testing of it, to a stream or river. It’s a long stream of code that starts at the source and flows through turns, falls, and rapids to the customer base. And the QA issues we all face are like some of the situations normally encountered along a river.

Read on below for a discussion of QA testing and the river of product development where it takes place.