Are you getting the most out of Quality?

Testing != Quality.

Now that we've gotten that out the way, let's talk about why.  Testing is an essential activity in any quality system, but it should never be the focus.  Testing should be used to verify that your quality is working, not to verify that your product is working - because if you have a quality process fueled by quality input then you can predict a certain level of quality product.

There is something to be learnt from looking at the history of quality, long before we needed to apply it to software.  Before the industrial revolution which saw mass manufacturing on production lines, all we had was testing.  Quality of output was a function of the individual craftsman - pieces were all made and inspected manually.  Clearly this process couldn't scale to outputs in the tens of thousands of units per day, as some production lines were capable of, and so we needed a way to ensure the quality of our output without having to individually inspect every single unit.  And thus, quality was born.

The key was focusing on the process; ensuring that materials, practices, and tools adhered to a certain standard to create consistent output.  This way, inspecting the output became the way we tested the process, not the units, and we could afford to take samples instead of reviewing every individual item.

I am surprised by how many organisations still have a 'testing the output' approach to quality, they could be spending their time so much more wisely.  There are a whole bunch of things that make up quality in software projects; the architecture, the specifications, the documentation, the environments, the project management, and the testing which proves it was all done adequately.

Invest in quality, not in testing, inspect samples only, and automate a complete exercise of all your functionality (what it should do and what it should not do) before you ship.