3.3Risk-Based Arguments vs Authority-Based Arguments

The difference between effective and ineffective release blocking comes down to how you make your case.

Authority-Based Arguments (Weak)

Authority-based arguments rely on the QA engineer's role as a gatekeeper:

• "I'm QA and I haven't signed off on this."
• "We haven't finished testing yet."
• "The process says we need QA approval."
• "I don't feel confident about this release."

These arguments fail because they are based on position rather than evidence. They invite the response "We're shipping anyway" because they do not give decision-makers information they can act on.

Risk-Based Arguments (Strong)

Risk-based arguments present data, consequences, and alternatives:

• "Three of the five payment flows have untested paths. If any of them fail, customers will be charged without receiving their order. Here is the list of untested scenarios."
• "We have 4 critical bugs open in the checkout flow. Based on our traffic patterns, approximately 2,000 users per hour will hit the affected code path."
• "The migration script has not been tested against a production-size dataset. In our staging test with 10% of production data, it took 45 minutes and timed out twice. At production scale, we could have 4+ hours of downtime."

The Structure of a Risk-Based Argument

1. WHAT is the risk?
   "The password reset flow does not validate email format."

2. WHO is affected?
   "Any user who triggers a password reset -- approximately 500 users/day."

3. WHAT is the impact?
   "Users enter an invalid email, receive no reset link, and cannot
   access their account. Support ticket volume will increase."

4. HOW LIKELY is it?
   "High. 8% of our users have typos in their email addresses
   based on our registration data."

5. WHAT is the alternative?
   "We can either delay by 2 hours for a fix, or ship with the
   known issue and add client-side email validation in a hotfix
   tomorrow."