A tester leaves mid-cycle holding a large queue of items. How do you reassign that work in a test management product without disturbing the cycle's numbers?

## What a handover actually changes Reassignment writes a different owner onto a cycle item. That is all it does. The item keeps its result, its comments, its attachments, and its record of who reported what and when. Understanding that gives you the verification step which makes the whole operation safe: **after a pure ownership sweep, every progress figure must be unchanged.** Executed, remaining and blocked are computed from results, and you did not touch a result. If a number moved, the bulk edit did more than you asked for. ## The sweep, in order 1. **Enumerate before you disable.** Find every open cycle -- not just the one in front of you -- and filter each by the departing owner. Once the account is deactivated, filtering by that person ranges from awkward to unavailable in this class of product, and you lose the list at the moment you need it. 2. **Split the queue by result state.** Rows carrying a recorded outcome are finished work; rows that are untested or blocked are outstanding. Only the outstanding rows need a new owner. 3. **Leave the finished rows alone.** The owner attribute says who was *expected* to run an item; the result history says who *did*. Rewriting the owner on a completed row tells a later reader a small lie and dumps a pile of already-done items into somebody's working list. 4. **Reassign the outstanding rows in bulk over a filtered selection**, in slices small enough that a mistake is recoverable -- by folder, by area, or by whoever is picking up that part of the cycle. 5. **Handle blocked rows deliberately.** A blocked item needs somebody to chase the impediment and re-run the item once it clears. Read the blocking note before choosing the inheritor; the right owner is often whoever owns the blocker, not whoever took the rest of the folder. 6. **Verify the counts.** Compare executed, remaining and blocked before and after. Identical is correct. Anything else is a signal to go and look at what the bulk action offered to change. 7. **Then deactivate the account.** The departed name stays in the result history for audit; that is what the history is for, and nothing in a handover should erase it. ## The trap in the bulk editor Bulk actions in this class of product tend to expose several attributes in one pass, and one of them is usually the result. Changing owner and clearing results together is tempting during a handover -- nobody quite trusts the departed tester's runs anyway -- and it is two decisions wearing one coat: - **Reassignment** is an allocation change. Its correctness test is that the numbers do not move. - **Clearing results** is a decision to re-run work. It is sometimes right, it needs its own justification, and doing it in the same pass destroys the check that would have told you the reassignment behaved. Do them separately, in that order, with the count comparison in between. ## Choosing who inherits | Situation | Sensible handling | |---|---| | One colleague can absorb the whole queue | Reassign wholesale, then look hard at their total load | | The queue is larger than any one person | Split by area so each new owner keeps a coherent slice | | Nobody can take it this cycle | Leave those rows unassigned on a standing unowned view, rather than parking them on somebody who will not run them | The last row matters more than it looks. Assigning work to a person who cannot do it is worse than leaving it unowned: an unowned item is visibly nobody's, while an item parked on an overloaded tester looks handled in every view anyone reads. ## What you carry away - Ownership and outcome are independent; a handover touches only the first. - The verification is free -- the counts must not move. - Sweep every open cycle, and do it before the account goes. - The audit trail belongs to whoever recorded the result, not to whoever owns the row today. - An unowned row on a watched view beats a parked row in a queue nobody can work.