A test cycle in a case-management tool shows every item green, but several items failed earlier in the week and were re-run after fixes. How do you keep those earlier failures visible to whoever reads the cycle?

## What the green cycle is not telling you A cycle that reads as all-green after a week of fixes is not lying, and no data has been destroyed. Every failing attempt is still stored on its execution — the pairing of a case with this cycle — carrying the outcome, the tester, the timestamp, the comment and whatever evidence was attached at the time. What happened is a **reduction**: the board shows one status per item, and that status is derived from the newest attempt. Everything before it is true, retained, and invisible. The consequence is that two very different weeks render identically. A cycle where nothing ever failed and a cycle where a third of the items failed and were fixed both display a wall of green. The reader with the most at stake — the person deciding whether to ship — is usually the one furthest from the execution detail, so they see only the reduced view. ## Where the earlier attempts actually live - **On the execution.** Opening an individual item shows its attempt list in order. This is complete but does not scale: nobody opens two hundred items. - **In an attempt-level export.** Most repositories can emit one row per recorded **result** rather than one per item. That export is the artefact that carries the history off the platform. - **In the activity trail.** Status changes are logged with actor and time, which reconstructs the sequence even where per-attempt evidence is thin. - **In linked defects.** Tickets raised from a failing attempt persist independently, so the defect list is a partial shadow of the failures — partial, because not every failing attempt produced a ticket. ## Making it visible without changing the counts Resist the instinct to switch the cycle to worst-attempt counting. It makes this one cycle honest and every comparison with earlier cycles meaningless, and it turns the board into a red wall that no longer functions as a work queue. Add information instead: 1. **Re-run count** — how many items needed more than one attempt. One number, derived from the same rows, and it restores the whole distinction the green wall erased. 2. **Failing-attempt count** — how many failing results the cycle recorded in total. This separates one item retried eight times from eight items retried once. 3. **A repeat-offenders list** — the items with three or more attempts, by name. Short, and it is where the interesting reading is. 4. **The build each final attempt ran on** — so a reader can tell whether the greens were all produced against the same code. Then write two sentences of prose in the cycle summary. A tile cannot say "eleven items failed and were re-run after two fixes on Wednesday"; a person can, and that sentence is what actually travels into the decision. ## The pattern that should stop you An item with many attempts inside one cycle is a finding in its own right, and it deserves reading rather than counting. Open the per-attempt comments and ask which of these you are looking at: - **Different failures each time** — the item is walking through a chain of genuine defects, and the final green covers a lot of repaired ground. - **The same failure repeatedly, then a pass** — either a fix finally landed, or the last attempt ran under conditions the earlier ones did not. - **No build change between the failures and the pass** — the outcome moved without the software moving, which is the case that most needs saying out loud rather than absorbing into a pass rate. The attempt trail is the only place these three are distinguishable, and none of them survives the reduction to a single status. ## What to hand over For a cycle that will be cited as evidence, the deliverable is not a screenshot of a green board. It is: the pass rate with its counting rule named, the re-run count beside it, the repeat-offenders list, and an attempt-level export attached. That package is reconstructible months later by someone who was not there, which is the actual test of whether the earlier failures stayed visible. A useful habit is to look at the re-run count *before* the pass rate when reviewing your own cycle. It reorders the reading: instead of "we're green, any exceptions?", the question becomes "how much did this cycle have to absorb to get green?" — which is the question the stored attempts were keeping the answer to all along.