A common method of measuring software quality is by using software defect density, which is dividing the no. of defects encountered by lines of code for that module/product, or with function points. While this can be useful as a ballpark for prioritizing where to focus on in fixing defects, the method has its flaws. While LOC method is inaccurate in measuring code quality, function point method is subjective, and inappropriate for modern environments like CI/CD. In this article, let us look at some ways of how the software quality can be calculated for the modern environments with more accuracy.
Modern environments
Modern software development environments are characterized by
- Frequent changes to code based on fast feedback
- Integration with many third-party functionality
- Usage of multiple programming languages in the codebase
In these cases, it is difficult to use lines of code or function points to measure software defect density even as a ballpark. More so when there’s resistance to use lines of code as it is not accurate, and function points as it takes a lot of effort and time to go through the code and come up with no. of function point
What Matters In Software Quality?
What matters in software quality is how the defects are affecting the three things that are important for software quality – functional impact to the customer, risks, and key user journeys. I wrote an article about how to prioritize the tests to be conducted sometime back, and I feel that the same three attributes can be used in prioritizing defects to be fixed too!
Ways To Measure Software Quality
Code-based quantitative measurements, as discussed above, are not effective, so we need to be qualitative in measuring software quality. Luckily it seems to me that it is accurate to calculate the importance of a defect once it is categorized in terms of impact, risk, and effect on key user journeys. The formula can take into consideration each of the parameters and come up with a number for each defect, and prioritize defects from the highest number to the lowest.
Conclusion
I’m working on a conceptual model of how to implement this, and I’d be glad to talk about it in software quality or software testing conferences with the details. Software Defect Density may not be the right metric for Software Quality anymore, and I think the new model could be very useful in assessing Software Quality towards a software release, to the most important defects based on priority. If you would like to discuss further, please feel free to get in touch with me. Glad to collaborate!