In a TestRail-class case repository, a requirement-coverage panel reports a single percentage — what sits in the numerator and what forms the denominator?
answer
- it is a fraction, both halves configured
- the filter sets the denominator
- covered is a chosen condition
- one requirement, one vote
basics
~20 sThe denominator is the set of requirements the panel's saved filter selects; the numerator is how many of those satisfy the panel's configured covered condition. The unit counted is the requirement, not the test case.
solid answer
~40 sA requirement-coverage panel is a fraction over requirements. The panel's saved filter chooses the population — a release, a component, a label — and that population is the denominator. The numerator is the count of those requirements that satisfy whatever the panel treats as covered, and that condition is configurable: a link merely existing, a linked case executed in the selected cycle, or a linked case passed. Because the unit is the requirement, one requirement with forty linked cases contributes exactly one, and one case linked to five requirements contributes to five different requirements. Before quoting the figure anywhere, state which filter and which condition produced it; without those two facts the percentage is not comparable to any other reading of the same panel.
go deeper
Know that the panel counts requirements rather than cases, and that the percentage is the share of a filtered requirement set meeting some covered condition. Be ready to name the two facts you would ask for before repeating the number.
Be ready to explain how a many-to-many link graph collapses to one vote per requirement, and why a broad case linked to five requirements moves the figure five times as far as a deep case linked to one.
Show that you check the population and the condition before believing a coverage number in a release conversation, and that you read the uncovered list rather than the headline percentage.
Own which single coverage reading your organisation publishes and how it is qualified, because an unqualified percentage invites teams to optimise the filter and the definition instead of the testing.
## The panel is one fraction, and both halves are configured A requirement-coverage panel — the summary a case repository such as a TestRail-class product, or a tracker-resident tool like Xray or Zephyr, puts at the top of a requirement list — renders as a single number, and that visual simplicity is exactly what makes it misread. It is a fraction, and neither half of the fraction is fixed by the product. - **The denominator** is the **population**: the set of requirements the panel is currently looking at. That set comes from a saved filter — a release, a component, a label, an epic, a date window, or a hand-picked list. Change the filter and the denominator changes, with no change to any test artefact at all. - **The numerator** is the count of requirements in that same population that satisfy the panel's **covered condition**. Most products let that condition be chosen from a small ladder: a link exists at all, a linked case was executed in the selected cycle, or a linked case passed. So the honest reading of a coverage panel is always three-part: *this share of **this** requirement set meets **this** definition of covered.* Drop either qualifier and the number stops meaning anything a second reader can reconstruct. ## The unit of counting is the requirement The single most common misreading is to treat the percentage as a share of test cases. It is not. Coverage panels count requirements, and the link graph between requirements and cases is many-to-many, so the collapse from graph to fraction is lossy in two directions: 1. **A requirement with many linked cases still counts once.** Forty deep cases against one requirement and one shallow smoke case against another are, to this panel, the same: one covered requirement each. The figure carries no notion of depth. 2. **A case linked to many requirements counts many times.** One broad end-to-end case linked to five acceptance criteria can flip five requirements to covered in a single execution. This is why coverage percentages respond so much faster to *linking work* than to *testing work*. Some products link at the granularity of an acceptance criterion rather than the whole requirement. That changes what one row in the denominator is, and therefore changes the percentage, without changing anything about the tests. When two teams report coverage from products that link at different granularity, the numbers are not comparable even when both are honest. ## What the figure establishes, and what it does not | The panel tells you | The panel does not tell you | |---|---| | How many filtered requirements meet the covered condition | Whether the linked cases are any good | | Which requirements have no qualifying link | Whether the requirement itself is correct or complete | | The shape of the gap within the chosen population | Anything about requirements the filter excluded | | That work exists, at the strictness you configured | That the behaviour actually works, unless the condition is passed | The practical consequence: a coverage panel is a **completeness of the plan** instrument, not a quality instrument. It answers *have we pointed testing at everything we agreed to build, inside this slice?* — and only that. ## Reading a panel without being misled A short checklist that survives contact with a release meeting: - **Ask for the filter first.** A percentage without its population is a rumour. The dangerous filters are the ones that exclude unlinked requirements: the denominator shrinks, the number climbs, and the requirements most in need of attention are precisely the ones that vanished. - **Ask for the condition second.** Linked, executed and passed give three different numbers from identical data, and the gap between them is often the interesting part. - **Ask what a row is.** Whole requirement, or acceptance criterion? That decides the size of the denominator. - **Ask when the number was computed.** Some panels recompute on every read; others serve a stored roll-up refreshed on an event or a schedule. - **Read the uncovered list, not the percentage.** The panel's real value is the enumeration behind it — which specific requirements failed the condition — because that list is actionable and the percentage is not. ## Why the fraction moves the way it does Because the denominator is a filtered population and the numerator is a subset of it, the arithmetic has a few properties worth internalising. Adding requirements to the population without linking them **lowers** the figure — correctly, because newly agreed scope really is uncovered. Adding more linked cases to an already-covered requirement moves the figure **not at all**. Narrowing the filter to a component that happens to be well linked **raises** it without any testing having occurred. None of these movements are bugs; they are the direct consequence of counting requirements over a configured population, and a reader who has internalised the fraction predicts all three without being told.
- If one test case is linked to five requirements and it passes, how far can the panel move?Up to five requirements can flip to covered from that one execution, because the fraction counts requirements and each of the five gets its own vote. The case itself is never a unit in the sum. That is why a handful of broad, generously linked cases lifts a coverage figure far faster than many narrow ones, and why the percentage says nothing about depth.
- What does the panel do with a requirement that has no linked case at all?It stays in the denominator and fails the covered condition, so it pulls the percentage down — which is the useful behaviour. The trap is a saved filter that quietly excludes unlinked requirements from the population: the denominator shrinks, the figure climbs, and the requirements that most needed attention are the ones that disappeared from view.
It is an attendance register, not an exam mark: it records that every name on the list was signed against, and says nothing about how well anyone did.
saying these in an interview costs you the question
- Reads the percentage as a share of test cases
- Assumes covered always means a case passed
- Quotes the figure without naming the filter behind it
- Thinks adding linked cases to a covered requirement raises it