In a TestRail-class test-management tool, what happens to the first result when a tester records a second attempt on the same case in the same cycle?

## What actually receives a result A case in the library is a **template** — steps, expected results, custom fields — and it carries no outcome. When the case is pulled into a cycle (called a run, a test execution or a suite instance depending on the product), the tool creates an **execution**: the pairing of *this case* with *this cycle*. The execution is what holds a status, an owner and a history. Recording a result never writes to the library case; it writes against that pairing. That is why a second try has somewhere to go. If a status lived on the case itself, a re-run could only overwrite it, because one case would have exactly one status forever. Because status lives on a per-cycle execution, the execution can own an **ordered list of attempts**, and a re-run simply adds one to the end. ## Append is the normal behaviour In mainstream case repositories — TestRail-class standalone tools, Jira-resident products such as Xray and Zephyr, Azure Test Plans-class suites and their peers — recording a result appends. The stored shape is: - the execution, whose current status is **derived** rather than stored on its own; - beneath it, attempt 1, attempt 2, attempt 3 …, each effectively immutable once written; - each attempt carrying its own outcome, tester identity, timestamp, elapsed time, comment, and whatever evidence was captured at the time — attachments, per-step outcomes, a linked ticket. "The item went from fail to pass" is therefore shorthand for "a passing attempt was appended, and the derived status now reflects the newest one". The failing attempt has not moved and has not been edited. ## Retained data, lost visibility The distinction worth carrying into an interview is this: **the earlier failure is kept, but almost nothing shows it.** The cycle board shows one status per row. Progress tiles count items, not attempts. Most roll-up exports emit one line per item with its current outcome. A reader who never opens an individual execution sees a green cycle with no hint that three of its items were red on Tuesday. So "does the product keep the first failure?" and "will anyone see the first failure?" have different answers — yes and no — and collapsing the two is how a bumpy cycle gets reported as a clean pass. ## Append versus overwrite | | Append an attempt | Overwrite the status | |---|---|---| | Earlier outcome | kept as a prior attempt | gone | | Attribution | tester and time per attempt | last writer only | | Evidence | preserved per attempt | replaced | | Counting rules available | latest-attempt or worst-attempt | latest only | | Typical source | a person recording in the interface | a bulk write keyed by case | Overwrite is not a myth; it lives mostly at the integration edge. A bulk result write designed as an upsert — "for this cycle, set this case to pass" — yields one row per case however many times it runs, so repeated automated attempts collapse into whatever the last write said. Nothing warns you, because from the tool's point of view exactly one result was recorded. ## How to check which behaviour you actually have 1. Record a fail on an item, then a pass, then open the execution and count the rows. Two rows means append. 2. Take an export and see whether it can emit one row per **result** or only one per **item**. An item-level-only export tells you the trail exists but will not travel. 3. Push the same case twice through the integration you really use, then look again. This is where a product that appends in the interface still ends up with a single attempt. 4. Check whether a comment or attachment added on attempt 1 is still reachable after attempt 2. If it is not, the tool is editing, not appending. ## Why this matters beyond trivia Three consequences follow. **Counting**: only an append model can offer worst-attempt totals at all, because only it still knows the earlier outcome. **Audit**: a release that rested on a green cycle can be re-examined later — who passed the item, when, on what evidence. **Diagnosis**: an item with six attempts inside one cycle is a finding in its own right, and that signal exists only because the attempts were kept. An overwriting integration destroys all three quietly, and it is usually discovered when someone asks a question the record can no longer answer.