What Is Test Coverage? How to Measure It and What to Aim For

Test coverage measures how much of your application's intended behavior your tests check, counted as the requirements, user flows, risk areas or platforms that have a passing test. It's usually shown as a percentage, the items you've covered divided by everything in scope. Code coverage, a different measure, counts the lines of code your tests run, so it can be high while checkout is broken.

What is test coverage?

Test coverage is the share of an application's intended behavior that has tests checking it. You pick a unit to count (requirements, user flows, risk areas or platforms), list everything in scope, and mark which items have at least one passing test.

The formula is:

Test coverage = (items with a passing test ÷ total items in scope) × 100

For example, if your app has 120 user flows and 90 of them have passing end-to-end tests, your flow coverage is 75%. Agreeing on the list of what should be tested takes far more work than the division, and it's the job of a test coverage plan.

Test coverage looks at the product from the outside, the way a user or a requirement describes it. It works for manual and automated tests, at any level, though teams use it most for functional and end-to-end tests, where each test maps to something a customer does.

What is the difference between test coverage and code coverage?

Code coverage measures how much of your source code runs when your tests run, while test coverage measures how much of the product's intended behavior your tests check.

• What each one counts. Code coverage counts lines, statements, branches and functions that executed. Test coverage counts requirements, user flows, risk areas or platforms that have a passing test.
• How each one is measured. Code coverage is measured automatically, by a tool that instruments the code, such as Istanbul for JavaScript, coverage.py for Python or JaCoCo for Java. Test coverage is measured against a list your team keeps, such as requirements, a coverage plan or a map of user flows.
• Who watches it. Developers watch code coverage, mostly for unit tests, and often set a minimum in CI. QA leads, product managers and engineering leaders use test coverage to decide what's safe to ship.
• What each one misses. Code coverage can't see a requirement nobody built, because there's no code to run, and it marks a line covered when it runs, whether or not an assertion checked what it did. Test coverage misses anything that isn't on the list.

Most teams track both, since code coverage shows developers which code no test touches and test coverage shows whether the things customers do get checked before a release. A suite can reach high code coverage with unit tests alone without ever logging in, adding an item to a cart and paying.

What are the types of test coverage?

The main types of test coverage are requirements coverage, user flow coverage, risk coverage, and platform and browser coverage. Each answers a different question, so most teams track more than one.

• Requirements coverage: the share of requirements, user stories or acceptance criteria with at least one test. It answers "did we test what we said we'd build?" Teams track it with a traceability matrix, a table that links each requirement to its tests, and it's only as complete as the requirements, since anything nobody wrote down has no row.
• User flow coverage: the share of the things users do, such as signing up, checking out or inviting a teammate, that an end-to-end test runs from start to finish. It answers "will the product work for customers after this release?" It's the measure closest to what customers experience, and the one QA Wolf uses.
• Risk coverage: the share of high-risk areas with tests, such as flows that make money, handle sensitive data, depend on other systems or changed recently. It answers "is what would hurt most covered?" A risk-based coverage model scores flows on those factors so the riskiest get tested first.
• Platform, browser and device coverage: the share of your users' browsers, operating systems, screen sizes and devices that your tests run on. It answers "does it work for everyone, or only on the laptop it was built on?" Cross-browser testing handles the web side, and mobile apps add OS versions and devices.

Code coverage has its own types, statement (or line), branch, function and condition coverage, all counting code that ran.

How do you measure test coverage?

To measure test coverage, list everything in scope, link each test to what it checks, and divide the items with a passing test by the total.

1. Choose what you're counting. Requirements, user flows, risk areas or platforms. For end-to-end testing, flows are the most useful unit, because each one is something a customer does.
2. List everything in scope, including the flows that don't have a test yet, so every gap shows up in the count. A test coverage plan keeps that list and the order you'll cover it in.
3. Link each test to what it checks. Tag tests with the flow or requirement they cover, so the count comes from the suite instead of a spreadsheet someone rebuilds each quarter.
4. Count only tests that run and pass. A skipped, disabled or failing test covers nothing until it's fixed.
5. Track it over time. Measure again after every release, and watch the metrics that show whether coverage is working, such as how many tests are skipped and how often they flake, next to the percentage.

For code coverage, the tool does the counting. Run your tests with coverage turned on, and it reports the share of lines and branches that executed.

What is a good test coverage percentage?

For end-to-end coverage, count against a list of your app's practical user flows, not every possible path through it. QA Wolf recommends covering at least 80% of that list as the minimum for effective coverage of any app, then working toward a test for every flow on it. Code coverage has no industry standard.

Teams set code coverage targets for themselves, often as a CI gate that blocks a merge when coverage drops. That threshold stops coverage sliding, but it can't tell you whether the product works.

QA Wolf's 80% recommendation comes from maintaining thousands of tests across hundreds of teams, where coverage below that level left gaps, especially in flows that cross services or rely on stateful data.

Weight the percentage by risk, since a high number that leaves out checkout is worse than a lower one that includes it.

Should you aim for 100% test coverage?

Not if 100% means every path through the app or every line of code, since neither is possible and chasing either wastes effort. Aim to test every practical user flow instead.

The paths through an app multiply without end. A shopper can check out with one pair of pants, or two, or ten, add a pair and remove it, change a size or apply a coupon, and each combination is a different path, so no suite can test them all. Code coverage has a different problem. Most codebases hold code no user ever reaches, such as old feature flags, unused admin paths and error handlers for cases that don't occur, and testing it spends run time and maintenance on nothing your users do.

A practical user flow is each distinct thing a user comes to do, such as signing up, checking out, inviting a teammate or exporting a report, along with the variations that change the outcome, like an empty cart, a declined card or an expired coupon. That list is finite, so you can count it, test all of it and keep it current.

• Test the variations that change the outcome, not every combination. Check one item, several and the maximum a cart allows, plus the failure cases, rather than every quantity.
• Covering every practical flow is affordable now. Picking a small subset of flows made sense when suites ran one test after another and people maintained every test by hand, so each test added run time and upkeep. With AI agents maintaining tests and every test running in parallel, an extra test costs little.
• Build coverage in risk order. Cover your critical flows first and get them stable, then expand. QA Wolf's advice is to go broad before going deep, testing every critical customer interaction across the product before writing edge cases for any one feature.
• New features get a test once they've been checked. A person checks a new feature first, for usability and anything a script can't judge, then the team builds an automated test for it so it keeps working release after release.
• The percentage is only as good as the list. Coverage measures what someone thought to write down. A requirement nobody captured, or a flow added last sprint, isn't in the total.
• Don't chase 100% code coverage. A line counts as covered when it runs, even if no assertion checks the result, so chasing the number invites tests that execute code and verify very little, including code no user reaches.
• Don't wait for a complete plan to start. Mapping a full test matrix before writing a single test is one of the reasons test coverage stalls before it gets started, so start on the critical flows while the list fills in.

How does test coverage decay without maintenance?

Test coverage decays as soon as the product changes and nobody updates the tests. QA Wolf benchmarks show that about half of end-to-end tests need changing or removing within six weeks without ongoing maintenance.

A test fails because a button moved, someone disables it to unblock a release, and the flow it covered goes unchecked. The suite still has the same number of tests, so nobody notices the gap until a bug in that flow reaches production.

New features add flows to the list, so coverage falls even when no test breaks. It's one of the reasons coverage can't keep up as a product grows.

Keeping coverage where it is takes steady work:

• Investigate every failure quickly, so real bugs get reported and broken tests get fixed before people learn to ignore them.
• Update tests in the same cycle as the change that broke them.
• Remove tests for flows that no longer exist, so they don't pad the count.
• Map the product again regularly, and add tests for new flows as they ship.
• Count coverage from passing tests only, so the number matches what's checked.

That work grows with every release, and it's the work QA Wolf's AI agents take on.

How does QA Wolf build and maintain test coverage?

QA Wolf's AI agents map your app, write end-to-end tests for the flows you choose, and maintain them so coverage holds as the product changes. When an agent needs an answer about how your product should behave, it asks your team.

• It starts with a map. QA Wolf's agent explores your app and maps its end-to-end workflows by feature or product area. The map shows where you have coverage, where it's missing and where regressions most often appear. The agent can also start from your existing test plans and recommend tests where coverage is missing.
• You choose what's covered. From the map, the agent proposes a coverage outline of the groups and flows to test, and you decide which flows get tests. QA Wolf recommends at least 80% of an app's user flows as the minimum for effective end-to-end coverage, and covers as many flows as you choose.
• The agents write the tests in Playwright and Appium. It's standard, open-source code you own and can take anywhere. On 1,567 evals across web, iOS and Android apps, QA Wolf passed 93%, against 78% for Claude Code and 74% for Codex.
• Every test runs at once. QA Wolf's infrastructure for web app testing and mobile app testing runs the whole suite in parallel, so adding flows doesn't make a run longer.
• The agents keep coverage from decaying. They investigate every failure, fix tests that broke because the app changed, with unlimited repairs, and report real bugs to you. When you ship new features, the agent can explore what changed and update the affected tests, so coverage stays current.

UserTesting is a perfect example. QA Wolf owns its regression coverage across legacy and new user journeys on web and mobile, with tests running daily, and twice a day in the parts of the product that change most. Its two-week QA cycles are down to under a day.

Start now and ask the agent to map your app and show where your coverage is missing, or talk to sales.