3.4Raising Blockers

A blocker is anything that prevents you from completing your testing work. Raise blockers early, clearly, and publicly. "I cannot test the checkout flow because the payment sandbox is down" is a blocker for standup, not something to mention casually at the end of the sprint.

Blocker Format

Every blocker should include three pieces of information:

1. What is blocked: The specific story, test, or task that cannot proceed
2. Why it is blocked: The specific dependency, issue, or missing resource
3. What is needed to unblock: The action required and who can take it

Example Blockers

BLOCKER: Cannot test SHOP-789 (checkout flow)
REASON: Payment sandbox returns 503 since Monday
NEEDED: Provider to restore service (ticket #45678 filed)
WORKAROUND: Can test non-payment checkout paths; payment tests deferred

BLOCKER: Cannot run integration tests
REASON: Staging database not refreshed with current schema
NEEDED: DevOps to run migration script on staging-db
WORKAROUND: Running tests against local database (partial coverage)

BLOCKER: Cannot test SHOP-801 (email notifications)
REASON: SHOP-800 (email service refactor) not yet deployed to staging
NEEDED: Developer to deploy SHOP-800 to staging
WORKAROUND: None -- email tests depend on the new service

Blocker Escalation

Duration	Action
< 4 hours	Mention in standup, work on other tasks
4-24 hours	Escalate to team lead, document workaround
1-3 days	Escalate to manager, propose alternative testing approach
3+ days	Impact sprint commitment, discuss with PO about descoping