skip to content

Who creates a traceability link from a requirement to a test case, and at what moment?

level: seniorimportance: should knowfreq 38%

answer

  1. Linking is part of the work
  2. Whoever creates it, links it
  3. Three or four moments, not one pass
  4. A required field beats a weekly sweep

basics

~20 s

The person producing the thing being linked creates it, at the moment they create it: the case author when writing the case, the engineer when opening the change, whoever files a defect when filing it. No separate scribe pass afterwards.

solid answer

~50 s

Linking belongs to whoever is producing the linked thing, at the instant they produce it, because that is when the connection is obvious and costs seconds. In practice: the requirement author assigns a **stable criterion identifier**; the **case author** names the criterion the case verifies, in a field on the case; the **engineer opening a change** names the work item carrying the requirement; **whoever files a defect** names the case that found it and the criterion it breaks; the **acceptor** reads the result and confirms the listed checks are the ones they meant. Nobody is assigned to update the record itself, since every entry is a field on something the person was already creating. Make those fields required at save or merge time rather than a convention, with an honest escape value for genuinely exploratory work.

code

pseudocode · 12 lines
pseudocode
ON save_case(case):
  IF case.verifiesCriterion IS EMPTY
     AND case.intent != "exploratory":
    REJECT "name the criterion this case verifies"

ON open_change(change):
  IF change.workItemRef IS EMPTY:
    BLOCK_MERGE "name the work item carrying the requirement"

ON file_defect(defect):
  REQUIRE defect.violatesCriterion
  OPTIONAL defect.foundByCase

go deeper

for a junior

Be ready to say that you name the criterion your check verifies when you write the check, not later, and that the reference is a field on the case itself rather than an entry somewhere else.

for a middle

Explain the several moments a link is created and who owns each, and why the person creating the work has information a later reconciler does not. Name the field that must be required.

for a senior

Show the enforcement design: required at save and merge, an explicit exploratory value, identifiers assigned at intake. Be ready to explain why a batched reconciliation pass fails when the team is busiest.

for a principal

Own the argument that link currency is a property of how the team works rather than of one person's diligence, and be ready to defend spreading a small cost across many people instead of funding a coordinator.

## Linking is part of doing the work The single decision that determines whether a traceability record is usable is whether creating a link is part of the work or a separate activity performed afterwards. When it is part of the work, the person who has the knowledge writes it at the instant they have it, and it costs a few seconds. When it is separate, someone with less knowledge reconstructs it later from names and dates, and it costs an afternoon a week. So the answer to "who" is: **whoever is producing the thing being linked**, not a coordinator, not a lead, and not a reviewer at the end. The answer to "when" is: **at the moment that thing is created**, while the connection is still obvious. ## The moments 1. **When an acceptance criterion is written.** It gets a stable identifier. Nothing can be linked to a statement that has no name, so this moment comes first and belongs to whoever writes the requirement. 2. **When a test case is authored.** The author names the criterion the case verifies, in a field on the case itself. This is the highest-value link in the record and the cheapest one to create, because the author cannot write the case without already knowing the answer. 3. **When a change is opened.** The engineer names the work item that carries the requirement. This is what later lets a reader move from a shipped change back to the promise it was meant to satisfy. 4. **When a defect is filed.** The person filing names the case that found it, if a case did, and the criterion it violates. Filing is the only moment at which both are known without investigation. 5. **When a criterion is accepted.** The acceptor confirms the listed checks are the ones they meant. This is a read, not an entry, and it is the one moment a person outside the delivery team touches the record. ## Who links what | Moment | Who | What they record | What it costs them | |---|---|---|---| | Criterion written | Requirement author | An identifier and one testable sentence | Seconds, once | | Case authored | Case author | The criterion this case verifies | Seconds, once per case | | Change opened | The engineer making it | The work item carrying the requirement | Seconds, once per change | | Defect filed | Whoever files it | The case that found it and the criterion broken | Seconds, once per defect | | Criterion accepted | The acceptor | Confirmation, not new data | One read | Notice what is absent: nobody is assigned to update the record itself. Every entry in the table is a field on something the person was already creating. ## Why a batched pass is the wrong default The tempting alternative is a weekly or per-release pass in which one person reconciles everything. It fails for three reasons that have nothing to do with diligence. - **The reconciler has the least information.** They were not in the design conversation and are guessing which criterion a case was written for, from its title. - **The cost is proportional to volume**, so it grows exactly when the team is busiest and gets skipped exactly then. - **The output is a copy.** A reconciled record is a second statement of facts already stored on the cases, changes and defects, and a copy made weekly is wrong for up to a week by construction. ## Making it hold without reminders Ownership survives when the link is a required field rather than a convention. - Make the criterion reference **mandatory on a case at save time**, with a genuine escape hatch such as an explicit "exploratory, no criterion" value, so that the empty case is impossible but honest exceptions are still expressible. - Make the work-item reference **a merge condition on a change**, checked mechanically rather than in review. - Put the field **on the object being created**, never in a separate place the author has to remember to visit. A field two clicks away is a field that gets filled when the author is unhurried, which is not most of the time. - Give the requirement author a **naming duty**: identifiers assigned at authoring time, never derived from titles, because titles are edited and identifiers are not. Two consequences are worth stating out loud in an interview. First, this arrangement spreads a small cost across many people instead of concentrating a large one on a single person, which is why it survives busy weeks. Second, it means the record's currency is a property of how the team works rather than of how conscientious one person was last Friday, and that is the whole difference between a record people trust and one they check by asking somebody.

  • What do you do about exploratory checks that verify no named criterion?
    Give the field an explicit value that means exactly that, rather than allowing it to be empty. An empty field is indistinguishable from forgetfulness, while a declared exploratory value is a claim somebody made on purpose and can be counted, reviewed and argued with. It also keeps the required-field rule honest, so people are not tempted to attach a nearest-fit criterion to satisfy a check.
  • The requirement author will not assign identifiers. What breaks?
    Everything downstream, because a link needs something stable to point at. Cases end up referencing titles, titles get edited, and the references quietly stop resolving with no warning. The cheapest repair is to assign identifiers on intake as a mechanical step rather than an authoring judgement, so that even a poorly written requirement is at least addressable.
  • How do you get engineers to accept a required reference on every change?
    Make it mechanical rather than social: checked automatically at merge, one field, with an obvious exception value for changes that serve no requirement. Reviews are the wrong place, because a reviewer asking for a reference costs two people a round trip while a check costs the author five seconds. What people resist is being nagged, not the field itself.

saying these in an interview costs you the question

  • Assigns one coordinator to enter every link weekly
  • Adds links during a review pass before release
  • Puts the reference somewhere other than the created object
  • Treats a missing reference as a reporting problem
  • Links by title, so renames break references silently
  • Leaves the field optional and relies on discipline