One Defect, Four Tickets, One Missing Attachment
A billing 403 became a Bug, two Stories and a clone across two Jira spaces, all with the same description pasted in — and the test data landed on the one ticket that never reached QA.
The story arrived in the QA column with a full description, a root cause analysis, and no way to start.
Everything explaining the problem was there. The one thing needed to reproduce it was not.
What the Defect Actually Was
An order push to the billing system had failed with a 403 and an invalid subscriptionRatePlanNumber. Clear enough as a defect: a specific call, a specific rejection, a specific field carrying a value the target system would not accept.
To retest it, you need the data. Not the narrative — the actual records, the plan numbers, the cart configuration that produces the failing payload. Without those you are not testing a fix, you are guessing at a shape.
The data existed. It had been attached to a ticket.
Four Tickets, Two Spaces, One Problem
Tracing where it went turned up something worse than a missing file.
The single reported defect existed as four tickets, spread across two Jira spaces. A Bug. Two Stories. And a clone, created as a working method rather than as an exception.
All four carried the same description, copy-pasted verbatim, root cause analysis included. All four sat in different statuses. The story delivered to QA was one of them. The attachment was on another — still in Story Drafting, and therefore invisible to anyone reading the delivered ticket.
Nothing was hidden and nothing was lost. The information had simply been distributed across four objects with no lineage between them, and the object I was given happened not to be the one holding the payload.
The Thing That Makes It a Process Finding
Identical descriptions are the tell.
When four tickets share one description word for word, they are not four pieces of work. They are one piece of work that the process had no way to represent, so it was represented four times. A defect that needs a fix, a story to carry the fix, another story for a related change, and a clone because cloning was faster than deciding what the second thing actually was.
The cost of that lands entirely on the last person in the chain. Four descriptions that agree tell a tester nothing about which ticket is authoritative. Four statuses tell them nothing about which state the work is really in. The single genuinely unique piece of content in the whole family — the attachment — was on the ticket furthest from delivery.
So the first task in QA was not testing. It was archaeology: open four tickets, work out which differences are real, and find the file.
What This Was Not
It was not carelessness by the person who attached it. They attached the data to the ticket they were working on. That ticket was, from their position, the right one.
It was not a Jira configuration problem either. Everything permitted was used exactly as permitted.
And it was not the bug. The 403 is ordinary — an integration rejecting a value, findable, fixable, the kind of defect a programme handles every week. The expensive part of this incident had nothing to do with the failure in the billing system.
The failure was that there was no clean Requirement → Story → Test Case lineage, so "one problem" smeared across types, spaces and statuses until no single ticket could tell you what to do. When that happens, Jira has stopped being a source of truth and become a set of places where truth might be.
Two Rules That Would Have Cost Nothing
Link, don't clone. A clone duplicates content and drops the relationship, which is precisely backwards — the content was never the scarce thing, the relationship was. A link keeps one authoritative description and makes the family navigable from any member of it.
And keep critical test data on the ticket that needs it. Not on the ticket where it was produced, not on the one the analyst had open. On the one that will reach the person who has to reproduce the failure. If that means attaching the same file twice, attach it twice — duplicating a file is cheap, and duplicating a description is what caused all of this.
Both rules are about the same asymmetry. The person creating tickets pays seconds to get this right. The person receiving them pays hours to work around it, and pays those hours inside the test window, where there is no slack left to spend.
If the tester only ever opened the ticket you delivered, could they start?