7.3When QA Should Say "No"

Anti-Pattern: Release decisions are made based on pressure, politics, or "it's probably fine." QA raises concerns verbally, gets overridden, and then absorbs blame when the release breaks.

Pattern: Pre-agreed release blocking criteria that remove politics from the decision. The criteria exist before the release conversation happens.

Release Blocking Criteria (Example)

• Any P0/P1 bug in the release scope
• Test suite pass rate below 95% (excluding known flaky tests)
• Untested critical paths (identified in risk matrix)
• Performance regression above threshold
• Security vulnerability in changed code

The Escalation Framework

When you believe a release should be blocked:

1. Document — Write down what you found, with evidence (screenshots, logs, test results)
2. Quantify — Express the risk in business terms: "This payment bug affects approximately X% of transactions"
3. Present options — "We can delay 2 days for a fix, release with a feature flag, or release and accept the risk"
4. Accept the decision — If leadership decides to release despite your recommendation, that is their prerogative. Your job was to make the risk visible and quantified. Document the decision.

The goal is not to block releases. The goal is to make risk-informed decisions. Sometimes the business reason to release outweighs the quality risk — and that is a legitimate decision when made with full information.