skip to content

Change History and Audit

2 roadmaps4 questions

The trail behind a case: who changed which field, when, and from what to what; comparing two revisions and restoring one; and what an outside reviewer needs it to prove about an old result.

on this pageshow

explore

questions

4

In a TestRail-class test case repository, what does a single entry in a case's change history record?

level: juniorimportance: must knowfreq 62%

answer

  1. who, when, which field
  2. before and after, per field
  3. one revision per save
  4. unchanged fields leave no row
  5. step tables flatten to changed

basics

~10 s

One change-history entry names the actor, the timestamp, and every field that save touched with its before and after values. Entries are per-field and append-only, so the trail never shrinks.

solid answer

~40 s

A saved edit produces one revision, and inside it one row for each field that actually changed: the field's name, its old value and its new value, plus a single actor and timestamp for the whole save. Nothing is overwritten — the case shows current values and the history is the append-only path to them, so fields the save did not touch produce no row at all. The actor is whichever identity performed the write, which for an import or an API-driven edit is the account behind the token rather than a person. Structured fields degrade: a step table edit is often recorded as a bare marker saying the steps changed, and attachments usually record only that one was added or removed.

go deeper

for a junior

Be ready to list the four things one entry carries: who saved it, when, which field changed, and the value before and after. Say plainly that the case shows the current state and the history shows the path to it.

for a middle

Explain why entries are per-field rather than per-document: unchanged fields write no row, one save groups the rows it did write under a single actor and timestamp, and structured fields such as step tables do not fit that shape.

for a senior

Show that you read a trail as evidence. Spot mass edits by identical timestamps, recognise that the actor may be an integration's account, and know that a trail records writes but not intent or approval.

for a principal

Own the consequence of the storage model: a per-field trail is cheap and readable but flattens step tables and attachments, so decide what your team is allowed to claim the history proves before anyone builds a process on it.

A managed test case repository stores two different things about every case: the **current** value of each field, and the **trail** describing how those values came to be. That trail is the change history, and it is assembled from entries. Knowing precisely what one entry carries is the difference between saying *there is an audit log* and being able to answer what a colleague or a reviewer actually asks six months later. ## The anatomy of one entry Saving an edit produces one **revision**, and that revision holds one row for every field the save actually changed. Between them, the revision and its rows answer four questions: - **Who saved it.** The identity that performed the write. That is a person when a person used the interface, the account behind the token when the edit arrived through the product's API, and the importing account when a spreadsheet or a migration wrote it. - **When.** A timestamp attached to the save. The whole revision shares it; individual field rows do not carry their own, which is why one save always reads as a single moment even when it touched a dozen fields. - **Which field.** The field's name — whether it is one the product ships, such as the title, the preconditions, the steps or the expected result, or one your team defined. - **From what, to what.** The value the field held before the save and the value it holds after. Fields the save did not touch produce no row, which is why one revision can be a single line and the next twenty. ## Per-field entries, not document snapshots There are two plausible ways to build a history, and repositories in this class overwhelmingly pick the first: | Model | What is stored per save | Consequence | |---|---|---| | Per-field entries | One row per changed field, with before and after values | Compact, reads as plain sentences, but structured fields flatten | | Whole-case snapshots | A complete copy of the case as it stood | Exact reconstruction at any point, much more storage, diffing done on read | The per-field choice explains both the strength and the weakness of these trails. The strength is that the history reads like a narrative — someone changed the expected result from one wording to another — with no diffing skill required. The weakness is that any field which is not a scalar or a block of text has to be squeezed into a before-and-after pair. ## Where the model gets thin 1. **Step tables.** Steps are rows, each with its own action and expected result. Inserting a step in the middle shifts everything below it, so a faithful per-field diff would be enormous and unreadable. Many products therefore write a single entry saying the steps changed: you learn *that* they moved, not *how*. 2. **Attachments.** Normally journaled as an addition or a removal by name. The bytes themselves are not versioned, so replacing a file with a same-named one can leave a trail that looks almost like nothing happened. 3. **Long free text.** Some products truncate the before value, or record only that a large field changed, to keep entries a sane size. ## Reading the actor correctly The actor is where trails are most often misread. Patterns worth recognising: - **Many cases, one actor, the same second.** That is a bulk edit or an import, not many separate decisions. - **A service identity.** Integrations, CI accounts and automation rules write as themselves. The entry is still accurate; it simply answers *which system* rather than *which person*, and the human sits upstream of it. - **A deactivated user.** Entries keep the actor as recorded at the time, so someone who has left the company still appears. The entry is a record of the past, not a live pointer at a current account. ## What the entry deliberately does not carry - **Why.** Unless the product offers a reason or comment on save, no entry explains intent. This is the gap teams discover latest and regret most. - **Approval.** That an edit happened is not evidence that anyone agreed to it. - **What was executed.** The trail describes the case's text; it says nothing about what a tester actually did. Treat one entry as a factual record of a write — actor, moment, field, before, after — and nothing more. Everything else a process needs, from a stated reason to sign-off, has to be carried by something your team maintains alongside the trail rather than assumed to be inside it.

  • The history shows the same actor on forty cases within the same second. What happened?
    That is one bulk operation, not forty decisions: a mass edit, an import, or an automation rule fanning out across a selection. Read it as a single act with a single reason, and look for whoever launched it rather than treating each entry as an independent judgement about that case.
  • Why does a case's history sometimes say the steps changed without showing what changed?
    Because steps are a row-structured table and the history model stores a before-and-after pair per field. Inserting or reordering a step would produce a huge, unreadable set of row diffs, so many products collapse the whole edit into one marker entry. You get the actor and the moment, but not the text that moved.

saying these in an interview costs you the question

  • Claims the history stores a full copy of the case per save
  • Thinks unchanged fields still appear in every revision
  • Assumes the actor is always a person, never a service account
  • Says a new edit overwrites the previous history entry
  • Believes attachment contents are versioned inside the trail
open as a page

In a managed test case repository, how does comparing two revisions of a case differ from restoring one, and what does a restore leave behind in the trail?

level: middleimportance: must knowfreq 55%

basics

~20 s

Comparing two revisions is a read-only, field-by-field diff. Restoring writes the old values back as a brand-new revision attributed to you, now — it never deletes the revisions in between, so the trail only grows.

open as a page

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?

level: seniorimportance: should knowfreq 48%

basics

~20 s

Two journals exist, not one. The tracker records changes to the issue's own fields, while the test tool keeps structured test data in its own storage with its own trail, retention and read permissions — so a step edit may be invisible in the tracker's history.

open as a page

A case's change trail is the only record of what a test case said when an old result was recorded. How do you decide how much of that trail your team needs, and how do you keep it readable?

level: principalimportance: nice to knowfreq 40%

basics

~20 s

Start from how long a recorded result must stay explainable, then check what the product actually keeps — in hosted tools the horizon is often fixed, not a setting. Readability is the bigger lever: keep mechanical churn out of versioned fields.

open as a page