skip to content

After a TestRail-class case repository files a defect from a failed execution, which two back-links exist, and what does each one answer?

level: middleimportance: should knowfreq 50%

answer

  1. one reference stored on each side
  2. cycle asks: is this red tracked?
  3. developer asks: which run produced it?
  4. half a pairing files it twice
  5. execution-level fact versus case-level claim

basics

~20 s

Filing writes two references, one on each side: the failed result carries the item's identifier, so a cycle can show that red as tracked, and the item points back at the execution that produced it. Half a pairing is the common defect.

solid answer

~50 s

Filing writes a pairing, not a single pointer. On the **repository side**, the failed result gains the tracker item's identifier, which is what lets a cycle view answer "is this failure already being worked, or is it an untracked red?". On the **tracker side**, the item gains a reference to the execution it came from, which is what lets a developer answer "where did this come from, in which cycle and on which build?". Each answers a question the other side cannot. When only one half is written — typically because someone filed the ticket by hand and pasted nothing back — the cycle looks like an untracked failure and gets filed again, or the ticket has a symptom with no provenance. Products also distinguish attaching the item to *this execution* from attaching it to the *case* itself, which is a much longer-lived claim.

go deeper

for a junior

Be able to say that filing writes a reference on both sides — the failed result shows the ticket, the ticket points back at the run — and that one without the other leaves someone stranded.

for a middle

Explain which reader depends on which half: the cycle reviewer asking whether a red is tracked, and the developer asking which cycle and build produced the defect. Then explain the execution-versus-case attachment choice.

for a senior

Describe the half-linked states you have actually cleaned up, why a hand-filed ticket produces duplicates, and what you test on an integration beyond the create path.

for a principal

Own the convention: whether hand-filed tickets are acceptable at all, who prunes stale case-level attachments, and how much a cycle panel is allowed to assert about a pairing it never verifies.

## Filing writes a pairing The naive mental model of filing from a failed run is one arrow: run creates ticket. The useful model is **two references, one stored on each side**, written at the same moment. They are not redundant; each answers a question that can only be asked from where it lives. - **The repository-side reference** hangs on the failed result: this execution has a tracked item, and here is its identifier. It is what the cycle view reads when it distinguishes *failed and being worked* from *failed and nobody knows*. - **The tracker-side reference** hangs on the item: this defect came from an execution, in that cycle, on that build, recorded by that person. It is what the developer reads before touching anything. A reader on either side wants to travel toward the other. Storing only one direction means one of those two readers hits a dead end. ## What each half is worth on its own | Question being asked | Answered by | Read by | |---|---|---| | Is this red already tracked? | the reference on the result | whoever reviews the cycle | | How many failures in this cycle are unaccounted for? | the absence of that reference | the person judging whether testing is done | | Where did this defect come from? | the reference on the item | the developer picking it up | | Which cycle and build reproduced it? | the reference on the item | anyone verifying a fix | ## The half-linked states, and what they cost 1. **Ticket exists, result does not know.** The classic outcome of filing by hand in the tracker instead of from the run. The cycle shows an untracked failure, so a reviewer chases it, and often files a second item for the same failure. The signal that testing is incomplete is a false alarm, and false alarms teach people to stop reading the panel. 2. **Result knows, ticket has no provenance.** Someone pasted an identifier onto the run but the item itself says only what a human typed. The developer has a symptom with no cycle, no build and no executor to ask, which is exactly the context the filing action existed to carry. 3. **Both references written, one target deleted.** The remaining side still displays a pairing that no longer resolves. Displaying a pointer is not the same as verifying it, and most panels do not verify on read. ## Execution-level versus case-level attachment There is a second decision hiding behind "the back-link", and interviewers who have used these products will probe it. Attaching the item to **this execution** says: *this run, in this cycle, failed because of that defect.* Attaching it to the **case** says: *this case has a known defect,* which persists across every future cycle until someone removes it. - Execution-level is a **historical fact**. It is true forever and needs no maintenance. - Case-level is a **live claim**. It stays visible after the defect is fixed unless somebody prunes it, and stale case-level attachments are how a case ends up wearing three closed defects that scare people off trusting it. The usual rule: file at the execution, and reserve a case-level attachment for a defect that genuinely characterises the case rather than one run of it. ## Why the two-sided write matters more than the copied text The pre-filled prose in a ticket is a snapshot; it drifts the moment either side is edited. The references do not drift, because they carry identity rather than content. That is why an integration that copies a beautiful summary but forgets to write the repository-side reference is worse than one that copies almost nothing and writes both halves. The prose can be rewritten by a human; a missing pairing is invisible, and the cost of it — a duplicate filing, a chased-down red, a defect with no provenance — is paid by someone who never knew the link was supposed to be there. ## What to check on a real integration - File from a failed run and confirm the **result** shows the item, not just that the item was created. - Attach an **existing** item to a second failed result and confirm both sides update — many teams only ever test the create path. - Detach and confirm both halves disappear; a stale one-sided reference is the residue that outlives the feature.

  • Why is attaching a defect to the case itself riskier than attaching it to the execution?
    An execution-level attachment is a historical fact: that run failed because of that defect, and it stays true without maintenance. A case-level attachment is a standing claim that the case has a known defect, and it keeps displaying after the fix unless someone prunes it — so cases accumulate stale warnings that nobody trusts.
  • A tester files the ticket by hand in the tracker instead of from the run. What is lost?
    The repository-side reference, mostly. The item exists and may even be well written, but the failed result still reads as untracked, so a reviewer chases it and may file a duplicate. The provenance the run would have supplied — cycle, build, executor — also has to be retyped, and usually is not.

A parcel handover: the courier keeps a signed stub and you keep the tracking slip. Either half alone proves something was handed over, but only both together let each side find the other's record.

saying these in an interview costs you the question

  • Thinks filing stores a single pointer, not a pairing
  • Pastes a ticket id in a comment and calls it linked
  • Attaches every defect to the case rather than the execution
  • Assumes a displayed link is verified on read