Catching and fixing defects in pre-production is important, certainly, but how much does it really tell us about software quality as a metric? Todd DeCapua would argue it offers very little. In an article for TechBeacon, DeCapua gets realistic, highlighting five metrics that he believes will make a real difference in the final quality of our software:
- Committed stories vs. delivered results meeting “doneness” criteria
- Quality across the life cycle
- Production incidents over time and recurrence
- User sentiment
- Continuous improvement
Quality Metrics, Quality Software
These five metrics are conceived in such a way as to be always monitoring results rather than merely activities. The intent of the first metric is to hold people accountable for the amount of work they take on, so that time and money are not wasted later on completing or reworking shoddy work. To that end, stories must be practical and meet formally agreed upon standards. And about the second metric, DeCapua acknowledges that the drive for fast software delivery is often at odds with the desire to manually test every build. He offers this in response:
The answer is to follow the build life cycle from story to code on a developer desktop. Next, you should check, build, and unit test. Continue by using automation through the rest of the process, including automated, functional, performance, security, and other modes of testing. This gives teams the ability to show the quality of a build throughout the life cycle with quality metrics and automated pass/fail gates…Now, your most frequent tests are fully automated, and you’re only doing manual tests on the highest quality releases that make it through the automated life cycle.
Regarding production incidents, the idea here is to track on a specified basis how well individual teams are committing to story delivery and avoiding production incidents. With that information, you can then examine why top-performing teams are doing so well and why underperformers are doing proportionately poorly. The metric of user sentiment meanwhile looks at simpler but no less vital concerns, namely about whether the software being made is usable, logical, and addresses evolving user needs. Within user sentiment, there might be dimensions of simplicity, stability, usability, and brand value.
Finally, there must be a conscious effort to build in and prioritize continuous improvement stories after a retrospective. When continuous improvement and its effects are measured, a case is built to further invest in the teams who are performing this commendable work. All in all, at the very least, employing these five metrics certainly will not harm your development efforts.
You can read the original article here: http://techbeacon.com/top-5-software-quality-metrics-matter-right-now