"It is not possible to tell the difference between high-quality code and poor testing."

For it is a dictate of common sense, that we can be under no obligation to do what it is impossible for us to do.
--Thomas Reid

"...defect removal in total has been the most expensive cost element of large software applications for more than 50 years."
--Capers Jones Estimating Software Costs

It's fair to say that current testing theory is based on the premise that "complete" testing is impossible. With this given, the idea is to make the most intelligent and practical selection of tests to run from all available tests given the time and resources available to you. The testing processes and techniques we employ in our projects are all a result of this practical necessity. We spend a lot of our time thinking about, and performing testing as the main activity to improve quality.

A new book, The Practical Guide to Defect Prevention, makes the argument for giving more attention to defect prevention. It seems to make argument that testing is necessary and fine as far as it goes, but it doesn't go nearly as far as we think given the amount of effort that we are willing to devote to it and the results we have gotten as an industry.

The authors argue that defect detection is the first and most common level of activity that teams undertake to improve software quality. "Test quality into the software". Many defects are detected this way, but nothing is done to prevent them recurring elsewhere in the application. The next level of software quality improvement is analysis. Previous defects are analyzed to see trends and find out why they weren't detected earlier. The long term goal and highest level is prevention. At this level active measures are used to identify and eliminate potential defects. The root causes of defects are found and used to eliminate them before they are introduced.

"The ultimate goal of any quality improvement effort should be to enable the development team to invest more time in defect prevention activity."

The low efficiencies of defect removal explain why there are often a long series of defect removal steps in software projects. When unit testing, function testing, integration testing, and system testing find less than 50% of the bugs present in an application, it is reasonable to question your quality improvement efforts and see if you are spending your time and resources most productively. I'll be giving defect prevention more consideration in my projects.