Written by: Chief Technology Officer
Dmitry ReznikPosted: 01.05.2026
16 min read
Anyone who relates to QA will tell you that there is no way to measure test coverage with 100% accuracy.
No matter what tools or metrics you use, if the test is performed manually or by automation. It's like you want to measure results which are currently shown as objects in a three-dimensional coordinate system with the use of the two-dimensional coordinate system diagram.
No matter how many metrics, tools or methods you try to use you will always have gaps in results - areas which were not measured. And even if you succeed with gathering such a massive amount of data it will require an inconceivable amount of resources and time.
What is test coverage?
Test coverage is a software testing metric that quantifies how thoroughly a test suite exercises an application, its code, requirements, features, user paths, and risk scenarios. It gives QA teams and stakeholders a measurable signal of how much of the system has been validated and where untested gaps remain.
Unlike code coverage, which counts executed lines of source code, test coverage is a broader concept. It can be applied to requirements, user stories, UI components, business rules, integration points, and risk scenarios, not just lines of code. This distinction is fundamental, and we will return to it in detail below.
Important! High coverage does not guarantee a bug-free product. Low coverage almost guarantees you will miss critical defects. The real value of measuring coverage is not hitting a target number, it is identifying what has not been tested and making an informed decision about whether that gap is acceptable.
How to calculate test coverage
The basic formula for calculating test coverage as a percentage is:
Test coverage (%) = (Number of executed test units / Total number of testable units) × 100
To calculate test coverage, follow these three steps:
Break down the software into testable units, such as functions, methods, or lines of code.
Execute your test suite and track the number of units covered by the tests, using testing tools or frameworks.
Calculate the test coverage percentage by dividing the executed units by the total testable units and multiplying by 100.
Example: If a test suite executes 750 out of 1,000 testable statements in a codebase, statement coverage is 75%.
What is a good test coverage percentage?
Most people in the industry say that aiming for 80% coverage is a good goal. This number isn’t just random, it’s based on weighing the costs and benefits: trying to test more than 80% usually takes a lot more work, and the extra effort to test those tricky edge cases often isn’t worth the small risk they carry.
What really matters isn’t just the overall percentage, but which parts of your code are covered. Even if you have 95% coverage, it could be risky if the missing 5% includes critical things like your checkout process, login system, or how errors are handled.
Learn how we helped Compass achieve 80% automated testing coverage
Test coverage metrics. Types and definitions.
Coverage metrics differ in what they measure and the depth of their analysis. These are the most widely used, ranked roughly from simplest to most advanced.
Statement coverage (line coverage)
Measures what percentage of executable code statements are executed at least once during testing. This is the most basic metric, useful for identifying dead code and completely untested modules, but insufficient on its own. A statement can execute without its logic being validated.
Branch coverage (decision coverage)
Measures whether each branch of every decision point (if/else, switch/case, ternary operators) has been evaluated in both directions – true and false. Branch coverage is significantly more rigorous than statement coverage. A test suite can achieve 100% statement coverage while missing entire branches of conditional logic.
Function coverage
Tracks whether every function or method in the codebase has been invoked at least once during testing. Useful as a sanity check, but low granularity, a function can be called without its internal logic being properly exercised.
Condition coverage
Evaluates whether each individual Boolean sub-expression within a conditional has been evaluated as both true and false, independently of other conditions in the same statement. More granular than branch coverage and often required in safety-critical systems.
Path coverage
Measures the percentage of unique execution paths through the code that have been tested. The most thorough code-level metric, and the most expensive. In any non-trivial codebase, full path coverage is practically impossible due to combinatorial explosion, but partial path coverage analysis identifies high-risk untested flows.
Mutation coverage (mutation score)
Tests the quality of your test suite, not just its breadth. The process introduces deliberate, small changes (mutations) to the source code, flipping a condition, changing an operator, and checks whether your tests detect them. A high mutation score means your tests are genuinely sensitive to logic errors, not just running through code without catching mistakes.
6 methods for measuring test coverage
Code-level metrics are only one dimension of test coverage. These six methods address different layers of an application and are applicable across manual and automated testing.
1. Coverage by feature (requirements coverage)
The most straightforward approach: compile a list of all features and requirements, then verify that each one has at least one test case covering it. This is the baseline, before asking how well something is tested, confirm that it is tested at all.
Best applied using a test coverage matrix (see below). Particularly critical in regulated industries where every business requirement must be traceable to a test case.
2. Coverage by code instrumentation
Uses tooling to track which lines, branches, and functions are executed as tests run. This is the primary method for measuring code-level metrics (statement, branch, function coverage) in automated test suites. Tools inject instrumentation at compile or runtime to collect execution data and produce coverage reports.
3. Coverage by GUI
Verifies that all user interface elements, screens, buttons, dropdowns, modals, tooltips, navigation links, form fields, are exercised by the test suite. For any user-facing application (web, mobile, desktop), UI elements are the primary interaction surface. Coverage by GUI ensures that the user experience layer is not left untested even when underlying code coverage is high.
This method is especially relevant for web applications where users may navigate via direct URLs or deep links, bypassing standard navigation flows. Test automation frameworks like Selenium, Playwright, and Cypress are used here.
4. Coverage by risk
Prioritizes testing based on the likelihood and impact of failure. Rather than aiming for uniform coverage across all features, risk-based coverage concentrates effort on the areas where a defect would cause the most damage, data loss, security vulnerabilities, payment failures, compliance violations.
The process: identify risks, score them by probability and impact, map them to test cases, verify coverage. This is how senior QA engineers think, not 'have we tested everything?' but 'have we tested everything that matters most?'
5. Coverage by user scenario (use case coverage)
Maps real user journeys to test cases. Instead of testing features in isolation, this method verifies that complete end-to-end flows work as expected — registration → login → purchase → refund, for example, not just each step independently.
User analytics tools (Hotjar, FullStory, Mixpanel) can inform which scenarios real users actually follow, preventing teams from over-testing hypothetical paths while under-testing the ones that matter. For new features without usage data, experienced QA engineers construct scenario libraries based on persona analysis and domain knowledge.
6. Coverage by state transition
Counts the number of valid state transitions (paths) through an application and verifies that each has been tested. A user can reach a confirmation screen via three different flows; each flow should be tested, not just one. This is particularly important for web applications with complex navigation, multi-step forms, and wizard-style UX flows where users may navigate non-linearly via browser history, deep links, or bookmarks.
Not sure which coverage methods apply to your project? DeviQA's QA engineers help engineering teams audit their current test coverage, identify the highest-risk gaps, and build a structured testing strategy, without disrupting active development cycles.
Book a free QA consultation
The test coverage matrix (TCM)
A Test Coverage Matrix is a table that shows how requirements, features, or user scenarios relate to specific test cases. It is the main tool for keeping track of and talking about functional and requirements-based coverage, especially on projects where stakeholders need to be able to see the link between what was specified and what was tested.
A basic TCM structure:
The matrix shows gaps right away: requirements that don't have any linked test cases, modules that only have one test when they should have three or four, and areas of redundant coverage where test cases can be combined.
You can keep TCMs in spreadsheets like Google Sheets or Excel, or you can use test management tools like TestRail, Zephyr, qTest, or Xray for Jira, which work with test execution and make automated traceability reports.
Test coverage versus code coverage
These two metrics evaluate the effectiveness of software testing and therefore software quality. However, they are often mixed up. That is why it makes sense to throw the light on the differences between them.
In a mature QA practice, both are tracked in parallel. Code coverage tells you what the tests touch; test coverage tells you whether they validate what matters. Neither is sufficient alone.
How to improve test coverage
1. Audit and eliminate redundant tests
Before adding tests, remove the ones that provide no incremental coverage value. Redundant tests slow CI/CD pipelines, inflate maintenance costs, and obscure genuine gaps. Review your test suite for duplicate assertions, tests that cover the same path with different variable names, and tests for deprecated code.
2. Build a test strategy before writing tests
Coverage improves faster with a plan than with volume. Define which modules carry the highest risk, which coverage methods are appropriate for each layer (unit, integration, E2E), which coverage thresholds you are targeting, and which platforms and devices must be validated. Track progress against the plan, not just against a percentage target.
3. Automate strategically, not comprehensively
Test automation dramatically increases the number of test cases that can be executed within a release cycle, but automation is not appropriate for every test type. Automate regression suites, smoke tests, data-driven scenarios, and integration checks. Reserve manual testing for exploratory testing, usability evaluation, and edge cases that require human judgment. Misapplied automation produces large test suites with low meaningful coverage.
4. Integrate coverage reporting into CI/CD
Coverage should be measured on every build, not manually on demand. Configure your CI/CD pipeline to run coverage tools automatically, fail builds that drop below your defined threshold, and surface coverage reports in your pull request workflow. This makes coverage a living metric rather than a periodic audit.
5. Use risk-based prioritization
In any real-world project, 100% coverage is unachievable and unnecessary. Focus coverage improvement efforts on high-risk, high-impact modules first. A structured risk analysis takes an hour. The defects it prevents can save weeks of incident response.
6. Apply coverage debt tracking
Just as teams track technical debt, track coverage debt: the accumulation of untested code and requirements that builds up as features ship faster than tests are written. Quantify it. Assign it a priority. Schedule coverage debt reduction sprints the same way you schedule refactoring. Teams that ignore coverage debt consistently find it compounding — each release adds more untested surface area than the last.
Advantages and limitations of test coverage measurement
Advantages
Reveals untested parts of the application before they reach production
Enables data-driven decisions about release readiness and exit criteria
Identifies redundant tests that can be removed to reduce maintenance overhead
Gives product managers and stakeholders a concrete signal of QA completeness
Supports compliance requirements in regulated industries that require traceability between requirements and test cases
Limitations
Test coverage cannot be measured with 100% accuracy, the combination of methods required to capture all dimensions creates inherent gaps
High coverage does not guarantee high-quality tests, a test can execute code without asserting correct behavior
Functional and requirements coverage analysis cannot be fully automated, it requires manual review of requirements and test cases
Coverage theater is a real risk: teams optimizing for metric targets may write superficial tests that inflate percentages without improving product quality
Full coverage of complex systems is prohibitively expensive, resource constraints always require prioritization
Conclusion
Test coverage is not a single number. It is a multi-dimensional picture built from code-level metrics, functional validation, risk assessment, and scenario traceability, each revealing a different category of gaps that the others miss.
The teams that get the most value from test coverage measurement are not the ones chasing 100% on a dashboard. They are the ones using coverage data to make deliberate decisions: where to add tests, where to remove them, where to accept risk, and when a release is genuinely ready to ship.
Start with the methods most relevant to your project type. Build a test coverage matrix. Integrate code coverage into your CI/CD pipeline. Prioritize by risk, not by volume. And track coverage debt the same way you track technical debt, because it compounds just as fast.
Is your test coverage strategy working? DeviQA has helped companies including Tipalti, Abbott, and Compass build test coverage frameworks that reduce critical defect escape rates without slowing release cycles. Our QA engineers review your current coverage posture and identify the highest-impact gaps, typically within the first two weeks of engagement.
Talk to a QA specialist
FAQ
What is the difference between test coverage and code coverage?
Test coverage measures how well your tests validate requirements, features, and user scenarios. Code coverage measures how many lines, branches, or functions in the source code are executed during testing. Code coverage is a subset of test coverage and is measured automatically by tooling. Test coverage is broader, more subjective, and requires structured analysis alongside tooling.
What percentage of test coverage is sufficient?
80% is the widely accepted industry benchmark for code coverage. For test coverage more broadly, the right threshold depends on the domain, release cadence, and risk tolerance of the application. Fintech, healthcare, and safety-critical applications typically target 85–95%. Lower-risk internal tools may be adequately served by 60–75%.
Can test coverage reach 100%?
In practice, no. Achieving complete coverage requires an exponentially increasing number of tests as system complexity grows, and the cost quickly exceeds the benefit. The goal is not completeness but confident coverage of the highest-risk functionality.
How do you measure test coverage for manual testing?
Manual test coverage is typically measured using a Test Coverage Matrix that maps test cases to requirements, features, or user scenarios. Since there is no instrumentation tracking execution automatically, manual coverage analysis requires regular review and updating of the matrix as features change and tests are added or retired.
Which tools are used to measure test coverage?
For code-level coverage: JaCoCo (Java), Istanbul/nyc (JavaScript), Coverage.py (Python), OpenCover (.NET), and SonarQube (multi-language). For test management and requirements traceability: TestRail, Zephyr, qTest, and Xray for Jira. CI/CD integration is commonly handled through Codecov or Coveralls.
What does 'coverage theater' mean in QA?
Coverage theater describes the practice of optimizing for coverage metrics without optimizing for coverage quality. A team engaged in coverage theater writes tests designed to execute code paths rather than to assert correct behavior, producing high coverage numbers while leaving significant defect risk. The solution is to combine coverage percentage tracking with test effectiveness metrics such as mutation score and defect escape rate.
About the author
Chief Technology Officer
Dmitry Reznik is the Chief Technology Officer and co-founder at DeviQA, bringing deep technical expertise across software architecture, implementation, and long-term system operation.