In the context of defining, evaluating, and measuring software quality, I’ve been discussing software testing metrics the last few weeks. I started out with defect metrics and a flowchart on how they flow through the development process and out to the customer. I’ve also discussed a total quality approach in various papers and journals. You may think it’s weird, but as I was lying in bed, I was thinking how to illustrate it so it all fits together in a diagram.

Software Quality Measurement Relationships Diagram

Measuring Software Quality in an Organization Includes More Than Just Defects

In a nutshell, establishing and implementing a measurement program for software quality needs more than software testing related metrics. Testing metrics (like defect statistics) are detective type metrics which are very late in the product life-cycle, and also only include one part of the organization. What about metrics that could prevent the defects to begin with? Or, what about corrective type metrics after you discover there are too many? As you can see from the 3 dimensions (could be more), other parts of the organization and its processes can also have an influence on the quality of the software. If you have other dimensions that should be included or other thoughts, please let me know.