Define a measure of bug publicness on a scale from 1 to 5 based on the publicness of the program element(s) in which or between which the bug is found. Base the measure on objective criteria such as testing level completed, degree of integration testing completed, appearance in documentation, and the scope of such documentation. Publicness of 1 is a bug caught in unit testing, designed and conducted by the programmer. Level 5 is a bug caught in the field after the program has been accepted by the buyer. Establish a follow-up program that allows relating repair costs to publicness (include travel costs, long-distance telephone, down-time etc.) Expect cost range 1 to 125 for publicness 1 to 5.
Propose a measure of bug severity on a scale of 1 to 10 based on the application, the environment, business concerns, management goals, applicable legal concerns, and moral issues. Explore and get agreement with upper management and senior staff re: applicability and practicability. Resolve differences by arbitration. Publish the measure and educate programming staff regarding its interpretation and application.
Design a set of technical bug categories that programmer can live with, making it as easy as possible for them to report the bug type. If the categories take more than one page it is too detailed. Use a few senior programmers to generate the first set and then subject it to criticism by a broader group. Iterate until mutual dissatisfaction is achieved.
Establish a reporting mechanism to gather statistics from the three measures above. Find what kind of bugs occur with that frequency. Temper that analysis by weighting the type by publicness and severity to obtain a perspective on the effort worth spending in preventing such bugs. Define importance as the product of severity, frequency, and publicness. Design educational plans, test methods, documentation and reporting structures in keeping with the importance of each kind of bug.
If the data remains stable over a few projects you have failed to improve software quality. If the factors do not increase and the type categories change then QA is being ignored and there are quality assurance bugs.