Software Quality Metrics
Software quality isn’t merely a matter of opinion—it can be measured. Metrics help teams quantify the state of their codebase, track progress, and spot potential issues early. This article introduces the key metrics and shows how to use them effectively.
In a Nutshell
- Metrics make software quality objective and comparable.
- Code coverage, complexity, error rate, MTTR, and technical debt are essential measures.
- Always evaluate metrics in context; never in isolation.
- A combination of technical, process-based, and operational metrics provides the clearest picture.
A Closer Look
A metric is a measurable quantity that reflects a specific aspect of software quality. It can measure technical properties of code—such as complexity—or process aspects, such as the time needed to fix a bug. What matters is treating metrics as indicators, not as the sole basis for decisions.
Key Metrics at a Glance
Technical Metrics
- Code Coverage: The percentage of code executed by automated tests. Typical targets range from 70 to 90 percent, depending on project context.
- Cyclomatic Complexity: Counts the number of independent paths through a function. Values above 10 are often flagged as problematic.
- Cognitive Complexity: Assesses how difficult code is for humans to understand.
- Code Duplication: Identifies repeated code blocks that are maintenance-prone.
- Technical Debt Ratio: The proportion of costly technical debt relative to the overall codebase.
Process-Based Metrics
- Defect Density: The number of bugs per unit of code size, typically per 1,000 lines.
- Bug Escape Rate: Defects that pass QA and reach production.
- Test Failure Rate: The proportion of failed test runs over time.
- Code Review Turnaround Time: How long it takes to complete a code review.
Operational Metrics
- MTTR (Mean Time To Recovery): Average time to restore service after an outage.
- MTBF (Mean Time Between Failures): Average time between successive failures.
- Availability: The percentage of time the system is operational.
- Error Rate: The proportion of failed requests in production.
- Latency: Response time of APIs or transactions.
Real-World Example: Team Quality Dashboard
Team Quality Dashboard:
Testing:
- Code Coverage: 82 percent
- Unit Test Failure Rate: 1.2 percent
- Integration Test Failure Rate: 0.5 percent
Code Quality:
- Average Cyclomatic Complexity: 6
- Code Duplication: 2.1 percent
- Technical Debt Ratio: 4.5 percent
Operations:
- Availability: 99.95 percent
- MTTR: 18 minutes
- Error Rate: 0.3 percent
Process:
- Code Review Turnaround Time: 4 hours
- Bug Escape Rate: 3 per sprint
- Defect Density: 0.8 per 1,000 lines
Strengths and Weaknesses
Strengths
- Objectivity: Decisions rest on data, not gut feeling.
- Early Warning: Negative trends become visible before they become critical.
- Comparability: Teams and projects can benchmark against the same metrics.
- Motivation: Clear targets foster quality awareness across the team.
Weaknesses
- Wrong Goals: High code coverage alone says nothing about test quality.
- Gaming: Metrics can be manipulated to hit targets without improving quality.
- Overhead: Collection and analysis require tools and time.
- Context Blindness: The same metric can mean different things in different projects.
Exam Study Notes
- Definition and purpose of software metrics.
- Distinction between technical, process-based, and operational metrics.
- Meaning and interpretation of code coverage and cyclomatic complexity.
- Relationship between MTTR, MTBF, and availability.
- Risks of isolated or manipulated metrics.
Typical Exam Questions (Quick Answers)
-
What does code coverage measure? The proportion of code executed by tests.
-
What is cyclomatic complexity? The number of independent paths through a function or module.
-
What does MTTR stand for? Mean Time To Recovery, the average time to restore service.
-
Why shouldn’t metrics be evaluated in isolation? Because they can easily be misinterpreted or manipulated.
-
Name an operational metric. Availability, error rate, or latency.
Next in the Software Quality Learning Path
The next article in the Software Quality learning path covers Software Testing Fundamentals—unit tests, integration tests, E2E tests, TDD, and BDD as the foundation of high-quality software.