skip to content

What does a retest outcome mean on a manual test item, and how does it differ from leaving the item untested?

level: middleimportance: nice to knowfreq 34%

answer

  1. which one is a request, not a sighting
  2. there was a result and it went stale
  3. usually triggered by a fix landing
  4. never readable as a soft pass

basics

~20 s

Retest means the item already has a result that is no longer trusted, usually because a fix landed under it, so it must be run again. Untested means no result exists at all. Retest invalidates evidence; untested records its absence.

solid answer

~50 s

Retest is the one common outcome that is a request rather than an observation. It says the item has been executed, something changed underneath the result - typically the defect it found is now claimed fixed, or the build moved mid-cycle - and the recorded evidence is stale. That is what separates it from untested, which asserts there was never a result to invalidate. It also differs from failed: failed is what the tester saw, retest is what someone did to that record afterwards once a fix was claimed. Either a person sets it, usually a lead sweeping items after a build lands, or a repository flips items whose linked defect the tracker now reports as fixed. The discipline that matters is not letting retest drift into a general parking space for uncertain results, because an item marked retest asserts no outcome at all and must never read as pass-adjacent.

go deeper

for a junior

Know that retest means the item ran before and its result is no longer trusted, while untested means it never ran. Say plainly that retest is not a pass.

for a middle

Explain that retest is a request rather than an observation, and describe what triggers it - a fix landing, a build change mid-cycle, or an integration flipping linked items.

for a senior

Demonstrate that you keep the mark honest: a reason or a defect link on every one, and something that drains the pile, because items sitting in retest are invisible work whose real state is a stale failure.

for a principal

Own the question of whether the word is worth having at all against simply resetting items, and argue the cost: a reset loses the history and the reason, which is precisely what makes the item actionable.

Most of the manual outcome vocabulary describes something a tester saw. Retest does not. It describes something that happened to a previous result, and understanding it as a request rather than an observation explains almost everything about how it should be used. ## An outcome that is not an observation When a case fails and the defect it found is fixed, the recorded failure becomes historically true but currently misleading: the product has changed underneath it. Marking the item for retest is how a repository says the stored result no longer describes the build in front of you and the item needs running again. Nobody looked at the product to produce that mark. It is a piece of workflow written into the outcome field. ## How it sits against the neighbouring words | Word | Was there a prior run? | What it asserts | |---|---|---| | Untested | No | No result exists; the item is outstanding work nobody has touched | | Failed | Yes | An observation: the product misbehaved when it was exercised | | Blocked | Attempted | An obstacle prevented the run; nothing was learned about the feature | | Retest | Yes | A prior result exists and is no longer trusted; run it again | The untested comparison is the one interviewers push on. Both mean there is no current, trustworthy result - but untested means there never was one, while retest means there was, it is on the record, and someone deliberately invalidated it. That history is the difference, and it is why a retest item usually comes with a link to the defect that caused it. ## Where the mark comes from - **A lead sweeping the cycle** after a build lands, marking everything whose defects that build claims to address. - **An integration with the tracker**: some repositories can flip linked items to retest when the defect they reference is reported fixed, so the queue rebuilds itself without anyone reading the release notes. - **A tester**, when the environment or the data changed under an item they already ran and they no longer stand behind the earlier result. - **A build change mid-cycle**, where results recorded against the earlier build are no longer about the thing now deployed. ## Keeping it honest The mark is cheap to apply and easy to abuse, and the abuses all have the same shape - using it to express something that is not why must this be run again: 1. **Retest as a soft pass.** Anyone reading an item as probably fine, someone will confirm has invented evidence. Retest asserts no outcome whatsoever. 2. **Retest as a parking space** for results a tester is unsure about. Uncertainty about what you saw is a failure needing better evidence, or a blocked item, not a request to run it again. 3. **Retest with no reason.** Without a link to the fix or a note about what changed, the next tester cannot tell what they are meant to confirm, and re-runs the case blind. 4. **A retest pile that never drains.** Because the mark is not an outcome, items sitting in it are invisible work. If nothing sweeps them, the cycle quietly carries a set of items whose real state is a stale failure. ## Why the vocabulary bothers A repository could get by without retest - a lead could simply reset items to untested. The reason it exists as its own word is that resetting destroys the connection between the item and the reason it needs running. With retest, the item keeps its history and the reader knows three things at once: this ran before, the earlier result is not to be trusted, and the run is expected soon. Untested says only the last of those, and says it about an item nobody has ever exercised, which is a materially different piece of work. The important reading discipline is that all four of untested, blocked, skipped and retest mean the item's current state is unknown. What differs is the history attached to the unknown, and whether there is a person, an obstacle or a fix behind it.

  • Who or what typically moves an item into retest?
    Usually a lead sweeping the cycle once a build lands, marking the items whose defects that build claims to fix. Some repositories automate it, flipping linked items when the tracker reports the referenced defect as fixed. A tester can also set it when the environment or data changed under a result they already recorded.
  • What goes wrong when retest becomes a general parking space for results a tester is unsure about?
    The word stops meaning a fix landed and starts meaning someone was uncomfortable, so nobody can tell which items are genuinely awaiting confirmation. Uncertainty about what you observed is a failure needing better evidence, or a blocked item with the obstacle named. Retest asserts no outcome, so a growing pile of it is invisible outstanding work.

saying these in an interview costs you the question

  • Reading a retest item as probably passing
  • Using retest for results the tester is unsure about
  • Marking retest with no link to the fix
  • Confusing retest with an item nobody has run
  • Letting a retest pile sit undrained all cycle