While a test cycle is still running, how do unassigned items land in the executed, remaining and blocked counts a test management product reports?
answer
- counts read results, not owners
- unowned is still in the denominator
- queues filter; the remainder matches none
- unowned and blocked is the bad cell
basics
~20 sUnassigned items count exactly like assigned ones. They belong to the cycle total and stay in remaining until a result is recorded, because the counts read the result and not the owner. Owner-filtered views hide them.
solid answer
~40 sThey count exactly like assigned items, because the progress figures read results, not owners. An item joins the cycle total the moment it is pulled in; it is remaining until an outcome is recorded, executed once one is, and blocked only if somebody recorded that state deliberately. Being unowned changes none of that. What it does change is visibility: a personal queue is the cycle filtered to one owner, and unassigned items match no owner, so they fall outside every per-person view at once. That is how four testers can each accurately report their queue as nearly done while the cycle's remaining count stays high. The cheap defence is a standing view of items with no owner and no result - and remembering that bulk-assigning that remainder moves no execution figure at all.
go deeper
Know that the counts a cycle shows are driven by recorded results, so an item with no owner and no outcome is still outstanding work inside the total.
Explain the arithmetic: the cycle total is the denominator, executed counts rows carrying an outcome, and blocked is a state somebody recorded rather than an absence of one.
Demonstrate the habit of comparing cycle-level figures with the per-person slices, and of hunting the unowned-and-untested intersection before a date is at risk.
Be able to set the convention for how cycle numbers are produced across teams: which figures a view publishes, how blocked and unowned work is surfaced, and who answers for the remainder.
## What the counts are made of A running cycle publishes a small set of figures, and each is derived from the **result** recorded on each item, never from who owns it: - **Total** -- every item pulled into the cycle. This is the denominator, and it is whatever the cycle currently contains. - **Executed** -- items carrying a recorded outcome. Pass and fail always count here; whether blocked counts as executed varies by product and by report. - **Remaining** -- the complement: items with no recorded outcome yet. - **Blocked** -- a state somebody recorded deliberately, meaning something outside the item stopped the run. Ownership appears in none of those definitions. That is the whole answer; everything else is a consequence of it. ## Where an unassigned item lands | The item's recorded result | Owner | Counts as | |---|---|---| | None | anybody or nobody | Remaining | | Pass or fail | anybody or nobody | Executed | | Blocked | anybody or nobody | Blocked, and usually outside the pass rate | An unassigned, untested item is therefore **remaining** -- indistinguishable, in the cycle totals, from an item sitting in a named tester's list. It joins the denominator the moment it is pulled into the cycle and stays there until somebody records an outcome or the item is removed from the cycle altogether. Two rows of that grid surprise people: 1. **Unassigned and executed** is ordinary, not exotic. Results pushed in from an automated run typically arrive with an outcome and no owner, so a heavily automated cycle can be most of the way executed while most of it belongs to nobody. 2. **Unassigned and blocked** is the worst cell in the grid. The item is correctly reported as impeded, and no name is attached to the job of chasing the impediment. It will sit there. ## Why the personal views do not add up A personal queue is the cycle filtered to one owner. Unassigned items match **no** owner, so they fall outside every personal view at once. The arithmetic is unavoidable: > the sum of every tester's remaining count, plus the unassigned remaining, equals the cycle's remaining > count If nobody looks at that middle term, four accurate personal reports produce one wrong picture of the cycle. This is the crux of unassigned work: **it is not hidden from the totals, it is hidden from the views people actually read.** The check is cheap. Filter the cycle for items with no owner and no recorded result, keep that as a standing view, and read it at the same moment you read the personal ones. Everything in it has been planned, is being counted against the cycle, and has nobody attached. ## Assigning is not executing The mistake also runs the other way. Because a large unassigned remainder is alarming, teams sometimes respond by bulk-assigning it and then feel better. Nothing moved: a pure ownership change is invisible to the arithmetic, so executed and remaining are identical before and after. What changed is that the work now appears inside somebody's list. That is a real improvement in visibility and it is not progress. ## State the denominator Whenever these figures leave the tool, say what they are over. A pass share computed over items that have a result is a different claim from the same share computed over the whole cycle, and the gap between them is exactly the untested remainder -- much of which, on a struggling cycle, is unowned. A rate quoted without its denominator invites the reader to assume the flattering one. ## Practical habits - Read the cycle-level figures first, then the personal slices, never the reverse. - Keep a standing view of unowned-and-untested items, and treat it as a queue with no owner. - Expect imported automated results to carry no owner; that is not neglected work. - Give any blocked item with no owner a name immediately -- an impediment needs a chaser, not just a status. - Quote every rate with its denominator, and say whether blocked items are inside or outside it.
- If a bulk import of automated results writes outcomes without an owner, how does that show up?The executed count moves and the assigned share does not. Imported rows commonly arrive with a result and no owner, so a cycle can be substantially executed while most of it belongs to nobody. That is harmless for the arithmetic, but it means the per-person views understate what has actually been run.
- How do you find the unassigned remainder without scanning every row in the cycle?Filter the cycle for items whose owner is empty and pair that with an untested result filter. The intersection is work nobody has picked up, and it is the first list to triage when a date is at risk. Saving it as a standing view turns a rescue into a routine check.
saying these in an interview costs you the question
- Says unassigned items are left out of cycle totals
- Treats an item with no owner as blocked
- Trusts the sum of per-person queues as the cycle total
- Reports a pass rate without stating the denominator
- Expects bulk-assigning the remainder to move executed