Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Integrating Quality Metrics
Previous articles in this series, such as "Using Metrics to Find Out if Your Code Base Will Stand the Test of Time" and "Where the Wild Bugs Are: A Primer on Finding and Taming Your Maintenance Nightmares," have covered some ways to measure whether you have bug-prone systems. Once you have a decent continuous integration environment set up, you can integrate these quality metrics into the build pipeline.
A common first step is to put code-coverage metrics into the pipeline, perhaps requiring some threshold of coverage (such as 90%) before a build can move into the QA environment. A good next step is to generate a report, perhaps using tools such as NDepend or similar, to provide automatic graphs visible on a common dashboard that show things like the following:
- Coverage over time
- Each class or package (depending on system size) on an instability over cyclomatic-complexity graph
- Exception report for those classes in the "zone of pain"—high instability with low complexity or coverage
As you move forward, it's also possible to start integrating other types of testing. Security testing, performance testing, and penetration testing are all good candidates for additional testing that can be put into the QA phase of the pipeline. When you have a mature continuous-integration process, you get as much visibility as possible into the level of quality of the software.