Glossary
Test coverage measures the percentage of an application that is exercised by automated tests. It quantifies how much of your code, logic, or user flows have corresponding test verification. The higher the coverage, the more of your application is protected against regressions.
Three types of coverage are commonly tracked. Line coverage measures the percentage of code lines executed during testing. Branch coverage measures the percentage of conditional branches (if/else, switch) that are exercised. Flow coverage (also called path coverage or user journey coverage) measures the percentage of end-to-end user flows that are tested from start to finish.
Line and branch coverage are measured with instrumentation tools like Istanbul/nyc (JavaScript), JaCoCo (Java), and coverage.py (Python). Flow coverage is harder to measure because there is no standard tooling. Most teams track it manually with a spreadsheet of critical user flows and which ones have corresponding E2E tests.
Test coverage is one of the most misused metrics in software engineering. The common mistake is treating 100% line coverage as a goal. Google's testing research found that the correlation between line coverage and bug detection plateaus around 70 to 80%. Beyond that, engineers write tests for trivial getter methods and configuration constants just to hit the number, without catching more real bugs.
The more valuable metric is flow coverage: what percentage of your critical user journeys have end-to-end test protection? A checkout flow with 100% line coverage in its React components can still fail if the payment API returns an unexpected response or if the confirmation email service is down. Flow coverage catches these cross-boundary failures.
For compliance-driven teams (SOC 2, ISO 27001), test coverage is evidence. Auditors want to see that critical application functions are tested regularly. Without measurable coverage, teams scramble to generate evidence at audit time.
Most teams track line coverage through CI tooling (Codecov, Coveralls, SonarQube) and enforce minimum thresholds per PR. Common thresholds range from 70% to 90% depending on the codebase. Some teams enforce that PRs cannot reduce overall coverage.
Flow coverage is tracked manually in most organizations. A QA lead maintains a list of critical user flows and checks off which ones have automated E2E tests. This list gets stale quickly as new features are added. Larger teams use test management tools like TestRail, Zephyr, or qase.io to map test cases to requirements.
The industry is moving toward risk-based coverage, where testing effort is proportional to the business impact of each feature. A payment flow that processes $2M/month gets more coverage than an admin settings page that five people use. This approach delivers better ROI than chasing universal coverage percentages.
Zerocheck provides flow coverage out of the box. Every test maps to a specific user journey, and the dashboard shows which flows are covered, which are untested, and which have failed recently. Coverage is measured at the flow level ("checkout: covered, onboarding: covered, password reset: not covered"), giving teams actionable visibility rather than abstract percentages.