In a test cycle status report, why is a blocked case counted separately from a failed one?

### The states, and the arithmetic behind them A cycle tracks every planned case in one of a small set of execution states. The usual set is **not run**, **passed**, **failed** and **blocked**, with **in progress** sometimes added for long cases. Two of these mean the case actually executed; two mean it did not, and that distinction is the whole point of the separation. The arithmetic is worth writing down because most reporting mistakes are arithmetic mistakes: ``` planned = passed + failed + blocked + not_run executed = passed + failed pass_rate = passed / executed <- denominator is executed, NOT planned coverage_of_plan = executed / planned ``` A pass rate computed over *executed* cases answers "of the things we managed to run, how many behaved". It says nothing whatsoever about the blocked and not-run remainder. Reporting the first number without the second is the single most common way a status report misleads without containing a false statement. ### Why blocked is a different kind of fact from failed A **failed** case is a claim about the product: it ran, it produced an oracle mismatch, and there is a result to investigate. It belongs to the development team's queue. A **blocked** case is a claim about everything *around* the product: the build was not deployed, the test data was not seeded, an upstream dependency is unavailable, an account could not be created, or a known defect sits earlier in the flow so the case behind it can never be reached. It belongs to whoever owns that obstacle, which is often not a developer at all. They also age differently. A failure is investigated once and either becomes a defect or becomes an invalid case. A block persists day after day and quietly grows: three cases blocked on Monday can be forty by Thursday if a dependency stays down. That is why a blocked entry is only useful with three extra fields — the **reason**, the **owner** of the obstacle, and the **age** of the block. Without them the state is a shrug. ### Blocked versus not run These are frequently confused. **Not run** is neutral: the case is still ahead of the cursor, and the cycle expects to reach it. **Blocked** is an obstruction: the case is at the cursor, or past it, and cannot proceed. The difference matters because not-run cases are a forecast problem (do we have time?) and blocked cases are an escalation problem (does someone need to unblock us?). A tool that lets a tester mark blocked without a reason will accumulate cases that are really just not run, and the escalation signal dies. ### A worked example An online bookstore checkout cycle plans 418 cases across cart, address, payment, tax and receipt. On day six the counts read: 251 passed, 12 failed, 37 blocked, 118 not run. Executed is 263, so the pass rate over executed is 95.4 percent — a number that looks like a nearly finished cycle. But executed is only 62.9 percent of the plan, and of the 37 blocked, 31 sit behind one obstacle: the seeded test data renders the order total in a locale-dependent format that the payment step rejects, so every case that reaches payment stops there. Read as two numbers, the report is honest: the parts we could reach are in good shape, and the entire payment-and-receipt half of the plan is unverified because of a data-format block that has been open for three days and belongs to whoever owns the seed data. Read as one number — "95 percent passing" — it is a report that will get a release shipped with its money-handling path untested. ### Re-tests and state churn When a block clears, the case does not become passed; it returns to **not run** and is executed normally. When a failure is fixed, the case is re-executed on the new build; the previous failure stays in the cycle's history but the current state is whatever the re-run produced. Teams that overwrite history lose the ability to see that one case has failed on four consecutive builds, which is a far stronger signal than one failure today. ### What an interviewer is listening for That you know the pass rate has a denominator and you can say which one you used; that you treat blocked as an escalation with an owner rather than a parking space; and that you never let "we did not test it" be reported in the same bucket as "we tested it and it worked".