Your test cases live as issues inside the issue tracker, managed by a Jira-resident tool such as Xray or Zephyr. Why can the question who changed this case's steps, and when, be hard to answer?

There are two broad shapes for a case repository. One lives **beside** the tracker as its own product; the other lives **inside** it, as an add-on that turns issues into test cases. The second shape is convenient — one login, one permission model, one place to look — but it splits the audit trail in a way that only becomes visible when someone asks a precise question about an old edit. ## Two stores, two journals A host tracker already has a per-field history for every issue: a field changed, from this to that, by this user, at this time. An add-on inherits it for anything it stores as an ordinary issue field. But test cases carry structure that does not fit a flat field: an ordered table of steps, each with an action and an expected result, sometimes parameters or per-step data. Add-ons typically keep that structure in **their own storage**, and journal it — or fail to journal it — on their own terms. So one logical edit can produce entries in either store, both, or neither: | Edited thing | Usually journaled by | What you see in the tracker's history | |---|---|---| | Title, description, labels, ordinary custom fields | The tracker | A normal before-and-after entry | | The step table and per-step expectations | The add-on | Often nothing, or one opaque entry | | Test-specific attributes the add-on defines | Either, depending on the product | Varies, and cannot be assumed | ## Four ways the split shows up 1. **A silent edit.** Someone rewrites the steps; the issue's history shows nothing that day. The natural conclusion — nobody touched it — is wrong. 2. **Different actors for the same act.** An edit made through the add-on's own screens may reach the tracker as a write by the add-on's service identity, while the add-on's internal trail names the person. Two truthful answers to *who*, at different levels of the stack. 3. **Different horizons and permissions.** The two trails are not kept for the same length of time and are not readable by the same people. Someone who can read the issue may see nothing test-specific; someone with test-tool rights may see the step history but not the issue's field history. 4. **Bulk operations land unevenly.** The tracker's own bulk edit and its automation rules fire against issues and land in the tracker's journal. Bulk operations run through the tool's own screens may only land in the tool's. ## Proving it rather than assuming it The useful senior move is to stop reasoning from documentation and run a controlled experiment on a scratch case in the same project, so configuration and permissions match production: - Change **one thing** — an ordinary field — save, and look in both trails. - Repeat for a **step edit**, an **attachment**, and a **test-specific attribute**. These are the four classes that behave differently. - Repeat once through the **API or an integration account**, because that is how most automated writes will actually arrive, and note which actor each trail records. - Write down the resulting map. It is a property of your configuration, not a universal fact, and it changes when the add-on or the field layout changes. Do this **before** anyone builds a process on the trail, not during the conversation where someone needs an answer about an edit from last quarter. ## Consequences for what you promise Once you know where each field is journaled, the promises become honest and narrow: - You can say *any change to these fields is attributable to a named person* for the fields the tracker journals. - For step edits you may only be able to say *the steps changed on this date, by this account* — which is still useful, and is very different from claiming line-level attribution. - Where an integration writes on people's behalf, the trail identifies the system, and the person is upstream of it. Say so plainly rather than letting a service identity be mistaken for a person. ## When there is only one trail A standalone repository beside the tracker avoids the split for the case itself: one store, one journal, one permission model, and the step table is journaled by the same product that journals the title. The complexity moves rather than disappears — the tracker item the work relates to keeps its own separate history over there — but for the narrow question *who changed this case's steps*, one trail is markedly easier to answer from than two.