After a fix lands mid-cycle, when should the failed items be re-run inside the existing test cycle, and when should a fresh cycle be created against the new build?
answer
- work queue or piece of evidence
- one cycle, one build
- untouched items still hold old-build verdicts
- width of the fix decides it
- link and name the successor cycle
basics
~20 sRe-run inside the cycle when it is a work queue and the fix is small; open a fresh cycle when the cycle is the evidence for a release decision and must describe one identified build.
solid answer
~50 sThe choice depends on what the cycle is *for*. As a **work queue**, a cycle tracks who still has what to do, and re-running failed items in place is right: the assignments, the progress view and the remaining-work count all stay coherent, and the attempt history keeps the earlier failures. As **evidence**, a cycle answers "what did build X do?", and re-running in place quietly breaks that: the cycle's results now span code before and after the fix, so its pass rate describes no single build. Rules of thumb — a small fix late in a cycle re-runs in place; a rebuild that changes what the untouched items would do earns a fresh cycle. If you open one, link it to its predecessor and name the build, because two similarly-named cycles with overlapping items are how a team loses track of which record the decision rested on.
go deeper
Know that a failed item can be re-run inside the same cycle, and that doing so adds an attempt rather than starting the cycle over.
Explain the consequence of re-running in place: the cycle then holds results from more than one build, and items never re-run still carry verdicts from the older one.
Judge it by the width of the fix and how much of the cycle is done, and make the record say which build each result came from rather than leaving it implicit.
Decide up front whether a cycle is a work queue or release evidence, and set the convention — naming, build identification, linking successors — so cited cycles mean one build.
## Two things a cycle can be Every argument about this reduces to a question nobody asks out loud: is this cycle a **work queue** or a **piece of evidence**? Both are legitimate, they pull in opposite directions, and most teams have never chosen. | | Cycle as work queue | Cycle as evidence | |---|---|---| | Question it answers | what is left to do? | what did this build do? | | Re-running in place | natural — it is the queue draining | corrupts it — results span two builds | | Lifespan | as long as the work takes | fixed to one build | | Reader | the team, daily | a reviewer, later | | Danger | none, until it is cited as evidence | proliferation of near-identical cycles | ## Re-running in place: what you keep and what you blur Recording a second attempt on the existing execution is cheap and coherent. Assignments stay put, the progress view keeps counting down toward zero remaining, and the attempt trail retains the earlier failure with its tester, timestamp and evidence. For a fix that touches one area late in a cycle, this is almost always right — opening a new cycle to re-run four items is ceremony with no reader. What it blurs is the build. After the re-run the cycle contains results recorded against at least two versions of the software, and nothing in the headline status says which. The items that were never re-run still carry outcomes from the **old** build, and their verdicts have not been rechecked against the new one. If the fix was broad enough to change what those untouched items would do, the cycle is now asserting something it has not tested. ## Opening a fresh cycle: what you buy and what it costs A new cycle against the new build gives one unambiguous record: every result in it was produced by the same code. That is what makes it citable months later without a paragraph of explanation. The costs are real: - **Effort** — re-running items that passed on the old build and were never in doubt. - **Fragmentation** — the story of the release now lives in several cycles, and the reader has to be told how they relate. - **Lost momentum** — a mid-flight cycle with half its work done does not transplant cleanly. The compromise most teams land on is a fresh cycle carrying only the items in question — the previously-failed set plus whatever the fix plausibly touches. It is cheap and it is honest about one build, but its pass rate covers only part of the release and must be read *together with* the cycle it followed, never instead of it. ## A decision procedure 1. **Ask who reads this cycle after it closes.** Nobody, or only the team? Re-run in place. A release reviewer or an auditor? Lean toward a fresh cycle. 2. **Ask how wide the fix is.** A localised change invalidates nothing else; a rebuilt dependency, a configuration change or a shared-component fix invalidates the untouched passes too. 3. **Ask how much of the cycle is already done.** Late and nearly finished argues for re-running in place; early and mostly outstanding argues for restarting cleanly on the better build. 4. **Ask whether the build is identified at all.** If the cycle does not record which build its results came from, a fresh cycle buys less than you think — fix the identification first. ## Keeping the record readable either way Whichever you choose, the record has to say what it is. If you re-run in place, note in the cycle summary that results span more than one build and which items were re-run — the attempt history holds the detail, but only a sentence makes a reader go and look. If you open a fresh cycle, name the build in the cycle itself and link it to its predecessor, so the sequence is obvious. Two cycles with similar names, overlapping items and no stated relationship are worse than either option done badly. ## The failure this prevents The outcome to avoid is a cycle presented as "the testing for release 5" whose results were actually produced against three different builds over ten days, with no marker anywhere saying so. Nothing in the tool is broken and every attempt is stored correctly, but the artefact claims more coherence than it has. Deciding up front whether this cycle is a queue or a record — and saying so in it — is what keeps the claim and the contents the same size.
- What do you lose by re-running everything in a fresh cycle instead of only the previously failed items?Mostly time, and it is often worth spending: a full fresh cycle gives one unambiguous record for the new build. A failed-subset cycle is cheaper but describes only part of the build, so its pass rate is not comparable with the earlier cycle's and has to be read alongside it rather than on its own.
- How should the two cycles relate to each other once you have opened the second one?Link them and name them so the sequence is obvious: the new cycle should state which build it covers and which cycle it follows. Two unrelated cycles with similar names and overlapping items are the quickest way to lose track of which record a release decision actually rested on.
saying these in an interview costs you the question
- Never questions which build a cycle's results describe
- Opens a new cycle for every single fix
- Assumes untouched passing items survive any rebuild
- Deletes the original cycle after starting a fresh one
- Cites a multi-build cycle as evidence for one release