What does reading a requirement-to-case traceability link forward tell you that reading it backward does not?
answer
- Same links, read two ways
- One read is asked at release
- The other is asked when pruning
- Requirement outward versus case inward
basics
~20 sForward reading starts at a requirement and asks which test cases verify it, answering whether anything checks it. Backward reading starts at a test case and asks which requirement justifies it, answering whether that case still earns its keep.
solid answer
~50 sThe same links are read in two directions to answer two different questions. **Forward** runs from a requirement, through its acceptance criteria, to the test cases that exercise it and the results those cases last produced. It answers *is this verified, and by what?* That is the release question, and before any code exists it is also the planning question: an empty forward read is a hole in the plan. **Backward** runs from a test case to the requirement that justifies it. It answers *why does this case exist, and what is lost if it goes?* That is the maintenance question, and it is what makes a suite prunable instead of untouchable. Neither is derivable from the other by inspection. The forward read cannot see a case that points at nothing; the backward read cannot see a requirement nobody linked.
code
pseudocode · 18 lineslink(requirement_id, criterion_id, case_id)
forward(requirement_id, build):
verdicts = []
for criterion in criteria_of(requirement_id):
cases = cases_linked_to(criterion)
results = [ latest_result(c, build) for c in cases ]
if cases is empty: verdicts.add(criterion, NO_EVIDENCE)
else if any(results == FAIL): verdicts.add(criterion, CONTRADICTED)
else if all(results == PASS): verdicts.add(criterion, VERIFIED)
else: verdicts.add(criterion, INCOMPLETE)
return verdicts -- feeds the release conversation
backward(case_id):
criteria = criteria_linked_to(case_id)
if criteria is empty:
return "no stated justification -- decide: re-point or retire"
return [ requirement_of(c) for c in criteria ] -- what breaks if this case goesgo deeper
Be ready to state both directions in one sentence each and say which question each answers. Interviewers ask this to check you understand that links are read, not merely recorded.
Explain the path a forward read actually walks — requirement, acceptance criteria, cases, latest results — and why the backward read is the thing that makes a growing suite prunable rather than untouchable.
Show when you reach for each: forward before a release conversation or over a new requirement with no cases yet, backward when the suite costs more than the confidence it returns. Say what each read is blind to.
Own the argument that a team needs both reads, and be ready to say which direction your organisation is currently blind in, what that blindness has already cost in duplicated work or an unprunable suite, and what you would change first.
## One set of links, two questions A traceability link is a recorded association between something that was asked for — a requirement, or one acceptance criterion inside it — and something that verifies it: a test case, and through that case whatever result the case last produced. The link itself is undirected. The **reading** is not. Starting from the requirement end and starting from the case end answer two different questions, support two different decisions, and are usually wanted by two different people at two different moments. Teams that think of traceability as a document to be produced tend to exercise only one direction — almost always the forward one, because that is the direction somebody asks for in writing. The backward direction is the one that quietly decides how expensive the test suite becomes over the following years. ## The forward read: what evidence exists The forward read starts at a requirement and walks outward: 1. From the requirement to its acceptance criteria — the individually checkable statements of what it means for the requirement to be met. 2. From each criterion to the test cases linked to it. 3. From each case to its most recent result on the build being discussed. 4. Back up to a verdict per criterion, and only then to a verdict for the requirement as a whole. It answers *is this verified, and by what?* That is the release question. When someone asks whether a feature is ready, the forward read is the shape of an honest answer: here is what was asked for, here is what checked it, here is what those checks last said. The same read is useful long before any code exists — a forward read over a freshly written requirement returns nothing, and that emptiness is the **plan** being incomplete rather than the build being broken. Reading forward early is cheap; reading it for the first time on ship day is not. What the forward read cannot see is a test case that points at nothing. That is not a defect in the read. It is simply the other question. ## The backward read: why does this case exist The backward read starts at a test case and walks inward: which criterion, and through it which requirement, justifies this case existing at all? It answers *why is this here, and what is lost if it goes?* That is the maintenance question, and it is what keeps a suite affordable. Every suite grows. Cases accumulate for a defect fixed four years ago, for a feature that was withdrawn, for an external behaviour that has since changed. With no backward read, nobody can tell a case that guards a payment calculation from a case that guards a decision nobody remembers making — so nothing is ever deleted, the pack slows down, and eventually people stop running it or stop believing it. With a backward read, retiring a case becomes a decision with a stated consequence rather than an act of nerve. ## The two reads side by side | | Forward read | Backward read | |---|---|---| | Starts at | a requirement or one of its acceptance criteria | a single test case | | Asks | what evidence exists that this was checked | why this case exists and what is lost without it | | Supports | the release conversation, and the plan before code | keeping, re-pointing or retiring the case | | Wanted by | whoever must answer are we done | whoever owns the suite runtime and its upkeep | | When it is absent | noticed at a fixed, loud moment | noticed rarely, and never loudly | | Typical failure it exposes | something asked for that nothing checks | a case nobody dares delete | ## Neither direction implies the other It is tempting to assume that if the links are recorded once, both reads come for free. They do not, because each read is blind to exactly what the other is about. - A requirement can have a clean forward read while one of the cases behind it also silently verifies behaviour belonging to two other requirements that nobody linked. The forward read of *those* requirements is wrong, and nothing in the first read reveals it. - A case can have a perfect backward justification and still tell you nothing about whether the requirement it points at has other criteria with no case behind them at all. So both directions have to actually be walked. Recording a link is a precondition for either read, not a substitute for performing them. ## What makes either read trustworthy - **When the link was made.** Links drawn after the testing is finished describe what was tested rather than what was asked for. A forward read over retrospective links reports everything verified, because the links were drawn outward from the cases that happened to exist. - **Results, not just existence.** A criterion whose only linked case last failed is not verified. A forward read that stops at the case and never reaches the result is a count of intentions. - **Stable identifiers.** If requirements or cases are renumbered without recording what replaced what, both reads break at the same instant. - **A named build.** Both reads are answers about a specific version. Detached from the build they were taken on, they are history, not evidence.
- With a release a week away, which direction do you read first and why?Forward, from every requirement in the release scope outward to its criteria, cases and latest results. That is exactly the question the sign-off conversation asks: is there evidence for what we promised, and where is there none? The backward read is maintenance work that pays off over quarters, and pruning a suite under date pressure is how a case that was genuinely protecting something gets deleted.
- A test case links backward to a requirement that was cancelled. Do you delete the case?Not automatically. The backward read says the case has lost its stated justification, not that it has lost its value — it may still be the only check on a shared calculation or a data migration that outlived the cancelled feature. Read what it actually asserts, re-point the link to whatever it genuinely verifies now, or retire it deliberately with the reason recorded. Silent deletion is how old regressions come back.
- Can either read be trusted when the links were all created at the end of the project?No. Links written retrospectively are drawn outward from the cases that happen to exist, so the forward read reports every requirement verified by construction. The backward read degrades identically: every case has a justification, because somebody chose one for it after the fact. Both reads are only as honest as the moment the link was made, which is why the timing matters more than the tidiness of the record.
A library catalogue read one way tells you whether a given subject is stocked at all; read the other way it tells you why a particular book is still on the shelf. Same cards, two entirely different decisions.
saying these in an interview costs you the question
- Thinks traceability runs in one direction only, requirement to case
- Treats the backward read as paperwork with no engineering payoff
- Assumes one direction can be derived from the other automatically
- Stops the forward read at the case and never reaches its result
- Deletes any case with no linked requirement without reading what it asserts