If several test cases each verify part of a requirement and each also touches other requirements, what does verified then mean?
answer
- Many-to-many runs in both directions
- A count of links is not a verdict
- Union of what the cases assert
- One shared case, several requirements affected
basics
~20 sLinks are many-to-many in both directions, so verified means every acceptance criterion of the requirement has a passing case behind it — not that the requirement has some cases attached. A count of linked cases proves attention, not completeness.
solid answer
~50 sThe relationship is many-to-many both ways, and each direction breaks a different naive reading. One requirement is usually verified by several cases, each asserting a different slice of it. So the forward verdict is a **union**: read what each linked case actually asserts, against what the requirement asked for, criterion by criterion. Four linked cases can still leave a criterion with nothing behind it, and a linked case whose latest result is a failure contributes no evidence at all. One case usually touches several requirements. So a failure implicates every requirement that case supports — but only the slice it asserted — and removing that case weakens all of them at once, which is invisible if you only ever look at it from one requirement. The honest claim is per criterion with a named build, never a count of links.
code
pseudocode · 14 lines-- forward: a verdict per criterion, never a count of links
verdict(requirement, build):
for criterion in criteria_of(requirement):
asserted_by = [ c for c in cases_linked_to(criterion)
if latest_result(c, build) == PASS ]
if asserted_by is empty:
report(criterion, "no passing evidence on this build")
else:
report(criterion, "asserted by", asserted_by)
-- backward: what a single shared case is holding up
impact_of_removing(case):
return [ requirement_of(cr) for cr in criteria_linked_to(case) ]
-- every one of these loses the slice this case assertedgo deeper
Be ready to say that one requirement usually needs several cases and one case usually touches several requirements, and that a number of links is therefore not the same thing as an answer.
Explain how a verdict is computed: per acceptance criterion, from what the linked cases jointly assert, using their results on a named build. Say why four links can still leave a criterion with nothing behind it.
Show the backward consequence in production terms: a shared case failing withdraws evidence from several requirements at once, and deleting one strips several. Describe how you state that precisely rather than alarmingly.
Own the reporting standard. Be ready to argue why a per-requirement verified flag misleads a decision-maker, what you would report instead, and what it costs a team to read unions rather than count links.
## Why the relationship is many-to-many in both directions It is tempting to picture traceability as one requirement paired with one test case. Real work never looks like that. Going outward from a requirement: a requirement of any size decomposes into several acceptance criteria, and each criterion usually needs more than one case — the accepted path, the rejected path, the boundary, the behaviour after a restart. A single requirement can easily sit behind a dozen cases, none of which alone establishes it. Going inward from a case: a case exercises a path through a running system, and a path crosses features. A case that places an order and checks the confirmation message touches the pricing rule, the stock rule, the notification rule and the audit rule. It asserts something about each, and nothing complete about any. The consequence is that **the presence of links is not a verdict**. It is the raw material a verdict is computed from, and the computation is not counting. ## What the forward claim actually requires A defensible statement that a requirement is verified needs three things, in this order: 1. **A decomposition.** The requirement expressed as acceptance criteria that can each be individually judged met or not met. Without it there is nothing for a case to be complete against, and the argument collapses into opinion. 2. **A union, not a count.** For each criterion, what do the linked cases jointly assert? Four cases all hammering the accepted path leave the rejection criterion with no evidence, and the requirement will still show four links against it. 3. **A result on a named build.** A linked case that last failed contributes no evidence, and a case that last passed on a build three weeks old contributes evidence about that build. The honest sentence at the end is not this requirement has coverage. It is: on this build, three of its four criteria have passing cases behind them and the fourth has none. ## What the backward direction adds Because a case touches several requirements, two things follow that are easy to miss when you only ever look outward from one requirement at a time. - **A failure implicates several requirements at once — but partially.** When a shared case fails, every requirement it supports loses the slice of evidence that case provided. It does not follow that all of them are broken; it follows that none of them can be claimed on the strength of that case until the failure is understood. - **Removing a shared case damages several requirements at once.** Deleting a case while looking at it from one requirement, having satisfied yourself that the others still cover this one, silently strips evidence from the other requirements it also served. | Reading | Naive version | What it actually requires | |---|---|---| | Requirement outward | it has linked cases, so it is verified | every criterion has a passing case on this build | | Case inward | this case belongs to one requirement | the case asserts a slice of several requirements | | A failing shared case | one requirement is broken | evidence is withdrawn from every requirement it served | | Removing a case | it was one requirement's case | check what else pointed at it before it goes | ## The counting trap, and why it survives Counting links is popular because it produces a number without requiring anyone to read anything, and the number always moves in the flattering direction: adding a case can only increase it. Reading the union can decrease it, because reading is how you discover that three of the four cases assert the same thing. The trap has a characteristic shape in a real team. A requirement is written broadly. Cases are added against the whole requirement rather than against a specific criterion. Everyone sees a healthy pile of links. The one behaviour the requirement was actually written to guarantee — the refund path, the failure after a partial write, the permission denial — has nothing behind it, and nobody notices until it fails in production and the record shows, embarrassingly, that the requirement was traced all along. ## Stating it honestly - Report per criterion, never as a single per-requirement flag, because a flag has to round partial evidence to either optimism or pessimism and both are wrong. - Say what the linked cases jointly assert in one sentence. If you cannot, that is the finding. - Name the build the results came from. - When a shared case fails, state which requirements have had evidence withdrawn rather than which are broken. - Treat a large link count on a requirement as a prompt to read, not as a result.
- One case shared by four requirements fails. What do you say about those four?That each has lost the slice of evidence that case provided, not that all four are broken. Read what the case asserted: if it failed at the pricing assertion, the pricing requirement is contradicted and the other three merely lose one piece of support that may be redundant with other cases. State the withdrawal precisely, then re-read each requirement's remaining evidence before making any release claim.
- A requirement shows twelve linked cases. Why is that not reassuring on its own?Because twelve links can all sit on the same criterion. The number rises whenever anyone adds a case and never reflects whether the criteria are jointly satisfied, so a broadly written requirement with a well-worn accepted path can look extremely well verified while the rejection or failure behaviour it was written to guarantee has nothing behind it at all.
saying these in an interview costs you the question
- Reports a requirement verified because it has linked cases
- Assumes each test case belongs to exactly one requirement
- Counts links instead of reading what each case asserts
- Treats a linked case that last failed as still supplying evidence
- Removes a shared case without checking what else pointed at it