Software Quality Metrics Glossary
Software quality metrics turn abstract ideas like "good code" or "reliable system" into measurable, trackable numbers. Teams use them to spot risk early, guide refactoring decisions, and prove that quality is improving (or slipping) over time. This glossary organizes the most widely used metrics into categories, with plain-language definitions and notes on how each one is typically applied.
Why Quality Metrics Matter
No single number tells you whether software is "good." Instead, teams combine metrics from several dimensions — code structure, defects, testing, performance, and process — to build a fuller picture. A codebase can have low complexity but poor test coverage; a system can be fast but insecure. Reading metrics together, rather than in isolation, is what makes them useful.
1. Code Quality & Complexity Metrics
Cyclomatic Complexity Measures the number of independent paths through a program's source code, based on its control flow graph. Higher values indicate more decision points (if/else, loops, switch cases) and generally correlate with harder-to-test, harder-to-maintain code. A common rule of thumb flags functions scoring above 10–15 for review.
Cognitive Complexity A newer alternative to cyclomatic complexity that tries to measure how difficult code is for a human to understand, rather than just counting logical branches. It penalizes nested structures and interruptions to linear reading more heavily.
Halstead Complexity Measures A family of metrics (program length, vocabulary, volume, difficulty, effort) derived from counting operators and operands in code. Used to estimate development effort and potential bug density.
Lines of Code (LOC) The simplest size metric — a raw count of code lines, often split into physical LOC (every line) and logical LOC (executable statements only). Useful for tracking codebase growth but a poor standalone indicator of quality or effort.
Maintainability Index A composite score (often 0–100) combining cyclomatic complexity, Halstead volume, and lines of code into a single maintainability rating. Higher scores indicate code that's easier to maintain.
Code Duplication (Clone Ratio) The percentage of code that is duplicated across the codebase. High duplication increases the risk that a bug fix or change is applied in one place but missed in another.
Coupling Measures how dependent modules or classes are on one another. Common variants include afferent coupling (incoming dependencies) and efferent coupling (outgoing dependencies). Lower coupling generally supports easier testing and change isolation.
Cohesion Measures how closely the responsibilities within a single module or class are related. High cohesion is associated with better-designed, single-purpose components.
Technical Debt Ratio An estimate of the cost to fix all quality issues in a codebase, expressed as a ratio against the cost of developing it from scratch. Often calculated by static analysis tools (e.g., SonarQube) as remediation time ÷ development time.
2. Defect & Reliability Metrics
Defect Density The number of confirmed defects divided by the size of the software (typically per 1,000 lines of code, or KLOC). Allows comparison of quality across modules or releases of different sizes.
Defect Removal Efficiency (DRE) The percentage of defects found and fixed before release, relative to the total defects found (pre- and post-release). A DRE close to 100% indicates strong pre-release testing.
Mean Time Between Failures (MTBF) The average time a system operates before experiencing a failure. Widely used in reliability engineering for systems expected to run continuously.
Mean Time To Repair / Resolve (MTTR) The average time taken to fix a failure and restore service once it's detected. A key metric for incident response and operational resilience.
Mean Time To Detect (MTTD) The average time between when a defect or failure is introduced (or occurs) and when it's actually discovered. Shorter MTTD generally limits the blast radius of an issue.
Failure Rate The frequency with which a system fails during a given period or number of operations, often expressed as failures per hour or per transaction.
Escaped Defects The number of defects that reach production despite testing efforts, as opposed to those caught earlier in the development lifecycle. A rising escaped-defect count often signals gaps in test coverage or process.
Bug Reopen Rate The percentage of resolved bugs that are reopened after being marked fixed. High reopen rates can point to inadequate root-cause analysis or rushed fixes.
3. Testing Metrics
Code Coverage The percentage of source code executed by an automated test suite. Common sub-types include line coverage, branch coverage, statement coverage, and path coverage. High coverage doesn't guarantee good tests, but low coverage is a reliable warning sign.
Test Case Pass Rate The percentage of test cases that pass in a given test run, used to track the health of a test suite over time or across builds.
Test Effectiveness The proportion of actual defects caught by testing versus those that escape to production, sometimes calculated similarly to Defect Removal Efficiency but scoped specifically to the test suite.
Mutation Score A measure of test suite quality produced by mutation testing: small deliberate faults ("mutants") are introduced into the code, and the score reflects the percentage of mutants the test suite successfully detects. A high score indicates tests are actually verifying behavior, not just executing code.
Requirements Traceability Tracks how thoroughly test cases map back to documented requirements, helping confirm that all specified functionality has been verified.
4. Performance Metrics
Response Time / Latency The time taken for a system to respond to a request, often reported as an average alongside percentiles (p50, p95, p99) to capture tail-end slowness that averages can hide.
Throughput The number of transactions, requests, or operations a system can process in a given time period (e.g., requests per second).
Resource Utilization Tracks how much CPU, memory, disk I/O, or network bandwidth a system consumes relative to its capacity, used to identify bottlenecks or inefficient code paths.
Scalability Not a single number but a measured trend — how throughput or response time changes as load or resources increase, often tested via load and stress testing.
Error Rate (Under Load) The percentage of requests that fail or time out during load testing, used to determine a system's breaking point.
5. Maintainability & Process Metrics
Code Churn The amount of code added, modified, or deleted over a period of time. High churn in a specific file or module can indicate instability or unclear requirements.
Change Failure Rate The percentage of deployments or changes that result in a failure requiring remediation (rollback, hotfix, patch). One of the four key DORA metrics used to assess software delivery performance.
Deployment Frequency How often an organization successfully releases to production. Another core DORA metric, used as a proxy for delivery agility.
Lead Time for Changes The time from code commit to that code running successfully in production. Shorter lead times generally reflect a more mature, automated delivery pipeline.
Cycle Time The time taken to complete a unit of work, from when it starts being actively worked on to when it's finished — a broader process metric often tracked alongside lead time.
Code Review Coverage The percentage of code changes that go through peer review before merging, used as a proxy for process discipline and knowledge sharing.
Comment Density / Documentation Ratio The ratio of comment lines to code lines, sometimes used as a rough (and contested) proxy for how well code intent is documented.
6. Security & Compliance Metrics
Vulnerability Density The number of known security vulnerabilities per unit of code (often per KLOC), typically surfaced by static application security testing (SAST) tools.
Mean Time To Remediate (Vulnerabilities) The average time taken to patch a known security vulnerability after it's discovered, often tracked separately by severity level.
Patch Compliance Rate The percentage of systems or dependencies that are up to date with required security patches at a given point in time.
Static Analysis Findings Counts of issues (bugs, code smells, vulnerabilities) reported by static analysis tools, often categorized by severity (blocker, critical, major, minor).
7. User-Facing & Business Metrics
Customer-Reported Defects The number of defects identified and reported by end users after release, as opposed to those caught internally — a direct signal of real-world quality.
System Availability / Uptime The percentage of time a system is operational and accessible, commonly expressed in "nines" (e.g., 99.9% = about 8.7 hours of downtime per year).
Net Promoter Score (NPS) / Customer Satisfaction (CSAT) While not code-level metrics, these business-facing scores are often tracked alongside technical quality metrics to connect engineering quality to user perception.
Service Level Indicators (SLIs) / Objectives (SLOs) SLIs are the actual measured values (e.g., latency, error rate); SLOs are the target thresholds an organization commits to. Together they operationalize "quality" into concrete, monitorable goals.
Choosing the Right Metrics
A few practical guidelines when selecting which metrics to track:
Pair leading and lagging indicators. Code complexity and test coverage (leading) predict problems; defect density and MTTR (lagging) confirm outcomes.
Avoid vanity metrics. Lines of code or comment density alone say little about quality — they matter only in combination with other signals.
Watch for gaming. Metrics tied to incentives (e.g., "increase coverage to 90%") can be gamed with shallow tests. Pair coverage with mutation testing or code review to keep it honest.
Track trends, not snapshots. A single measurement matters less than the direction it's moving — is defect density rising or falling release over release?
Used thoughtfully, these metrics give teams an evidence-based way to talk about quality — replacing gut feeling with numbers that can be tracked, compared, and improved over time.