When recording a manual test result in a case-management tool, what does a blocked outcome mean, and why is it not the same as failed?
answer
- one of them never executed
- ask what the tester actually observed
- an obstacle outside the case stopped it
- failure is evidence about the product
- blocked leaves the feature unknown
basics
~20 sBlocked means the tester could not execute the case at all, because an environment, data or dependency problem stopped the run. Failed means the case ran and the product behaved wrongly. Blocked describes the run; failed is evidence about the product.
solid answer
~50 sBlocked and failed both end a manual execution without a pass, but they carry opposite information. Failed says the tester reached the check and the product did the wrong thing, which is an observation about the product and usually the trigger for a defect. Blocked says the tester never got a clean look: the environment was down, a fixture or account was missing, a permission was absent, or an upstream defect stopped them reaching the steps this case is about. A blocked item has produced no evidence about its own feature, so the honest reading of it is unknown, not fine and not broken. Because blocked is a statement about an obstacle, the record only earns its keep if it names the obstacle, the build and environment it was seen on, and the step execution stopped at, so someone can clear it and re-run the item.
go deeper
Be able to say plainly that blocked means you could not run the case, while failed means you ran it and the product was wrong. Name one concrete blocker, such as a missing test account.
Explain why a blocked item carries no information about its own feature, and what the record must contain - obstacle, build, step reached - before anyone else can clear it and re-run the item.
Show the judgment call: an upstream defect blocks, a defect in the case's own feature fails. Expect to describe how you keep a team from parking uncomfortable results under blocked when a cycle is running late.
Own the consequence for how the organisation reads a cycle. Argue what the outcome vocabulary should be allowed to say, and why a word that means unknown must never be readable as a soft pass.
Manual execution records one outcome per item, and the vocabulary most case repositories offer is wider than pass and fail. Blocked is the word that gets misused most, because it is the only common outcome that says nothing whatsoever about the product under test. ## What each word actually asserts An outcome is a claim, and it is worth being exact about what the claim is about. | Outcome | What the tester did | What a reader may conclude | |---|---|---| | Passed | Ran the steps and saw the stated expectation | The behaviour under test was correct on this build | | Failed | Ran the steps and saw something else | The product misbehaved, and there is evidence to act on | | Blocked | Attempted the run and could not proceed | Nothing about the feature; something prevented the run | | Untested | Has not been picked up in this cycle | Nothing; no one has looked yet | Failed is an observation about the **product**. Blocked is an observation about the **run**. That single distinction is the whole answer, and everything else follows from it. A failed item has bought you information, expensively; a blocked item has bought you none, and the work still has to happen once the obstacle is gone. ## Where blocked legitimately comes from The obstacles are nearly always outside the behaviour the case was written to check: - the environment is down, mid-deploy, or running a build that does not contain the feature - a required account, licence, tenant or seeded data set is missing or expired - the tester lacks a permission the case needs, so a screen or action is unreachable - a dependency the case needs as scenery is unavailable, so the flow cannot be reached - an upstream defect, already filed against another feature, blocks the path to this case's steps That last one is the case people argue about. If a defect in the login flow stops a tester reaching checkout, the checkout case is blocked, not failed: checkout was never exercised, and recording it as failed would attribute a defect to a feature nobody looked at. Conversely, if the case is about login and login crashes, that is a plain failure, because the case's own feature is the thing that misbehaved. ## Recording a blocked result so someone can clear it A blocked result with an empty comment is close to worthless, because the only useful content of the outcome is the obstacle itself. A usable record carries: 1. **The obstacle, named specifically** - which service, which missing account, which defect identifier, not the word environment on its own. 2. **Where execution stopped** - the step reached, so a later reader knows how much of the case is genuinely unverified. 3. **Build and environment identity** - the obstacle may already be gone, and without this nobody can tell whether it was. 4. **A link to the blocking defect** if one exists, so the item is pulled along when that defect moves. 5. **Evidence of the obstacle** where it is not self-evident - a captured error is worth more than a description of one. ## How the vocabulary erodes The common failure modes are all pressure-driven, and each one destroys information at the moment it is recorded: - **Blocked as a softer failed.** A tester who saw the product misbehave but does not want to file a defect marks the item blocked. The evidence is then lost, because nothing downstream will re-derive it. - **Blocked as a synonym for ran out of time.** Nothing obstructed the run; it simply did not happen. That is untested, or a recorded decision not to run it, and calling it blocked invents an obstacle that no one can go and clear. - **Blocked with no attempt.** Blocked should imply someone tried. An item nobody opened is untested, whatever the tester believes about the environment. - **Failed used for an obstacle**, which does the opposite damage: it attributes a defect to a feature that was never exercised, and a reader chasing that failure finds nothing to reproduce. ## The reading that matters When the cycle is over, the pass and fail items are the ones that produced knowledge. Blocked items are outstanding work with a named reason attached, and untested items are outstanding work with no reason attached. Keeping blocked truthful at record time is what makes that distinction survive to anyone reading later, because the outcome word is the only place the difference is captured.
- A defect in the login flow stops a tester reaching the checkout screen. Is the checkout case blocked or failed?Blocked. Checkout was never exercised, so recording a failure would attribute a defect to a feature nobody looked at. The record should name the blocking defect so the item is picked up again when that defect is fixed, and note that execution never reached the first checkout step.
- What does a blocked result need in it before you would accept it from someone on your team?The obstacle named specifically rather than the word environment; the build and environment it was seen on; the step execution stopped at; and a link to the blocking defect if one exists. Without those, nobody can tell whether the obstacle still stands, and the item silently rots until the cycle ends.
Blocked is the delivery driver who found the road closed and never reached the door. Failed is the driver who reached the door and handed over a broken parcel. Both end without a happy customer, but only one of them tells you anything about the parcel.
saying these in an interview costs you the question
- Treating blocked as a gentler word for failed
- Marking a case blocked because it looks likely to fail
- Recording blocked without naming what blocked it
- Assuming a blocked item is probably fine
- Using blocked for items nobody attempted