Skip to content
SDETRole
SDETRole

QA Documentation

Test Coverage Calculator

Requirement, execution and code coverage with formulas explained.

Runs entirely in your browser No sign-up

Optional

Requirement coverage = requirements with at least one test ÷ total requirements × 100

Verified coverage = requirements whose linked tests all passed ÷ total requirements × 100

Count requirements from one baseline (a release scope, an epic) and use the same counting rule each time, or trends become meaningless. A traceability matrix gives you both numbers directly.

Result

Enter the total and covered counts.

About this tool

Three different numbers are all called "coverage", and they answer different questions. Requirement coverage asks whether every requirement has a test. Execution coverage asks how much of the planned testing actually ran and passed. Code coverage asks which code executed while the automated tests ran. This calculator handles all three and shows each formula. For code coverage, enter the four percentages from your Istanbul, Vitest, Jest, JaCoCo or coverage.py report and a threshold: it marks which metrics fail the gate and points out patterns, such as branch coverage far below line coverage, which usually means error paths and else branches are untested. It also states what coverage cannot tell you.

How to use it

  1. Pick the calculator: requirement, execution or code coverage.
  2. Enter the counts or percentages; results update as you type.
  3. For code coverage, set the threshold your CI enforces and read the findings.
  4. Copy the summary for a status report.

Test Coverage Calculator FAQ

Is 100% code coverage a good goal?

Rarely. The last few percent are usually defensive code that is expensive to reach, and 100% coverage still does not prove the assertions are meaningful. Many teams gate at 70–90% and review uncovered code in pull requests instead.

Why is branch coverage lower than line coverage?

A line with an if statement counts as covered when it runs once, but branch coverage needs both the true and false outcomes. A large gap means many conditions are only tested one way, often the happy path.

How can I tell whether my tests actually check anything?

Mutation testing (for example Stryker for JavaScript or PIT for Java) changes your code slightly and checks whether a test fails. Surviving mutants show code that runs under test but is not really verified.

Type to search across SDETRole.

Full-text search by Pagefind · runs in your browser Open search page →