Library › Book 21 › Saying No to Releases
Saying No to Releases
3.1🔒The QA Engineer's Hardest ConversationTelling your team that a release should not ship is the most consequential communication a QA engineer can have. Get it right, and you…
3.2🔒When to Block a ReleaseNot every bug justifies blocking a release. The decision to recommend blocking should be grounded in risk assessment, not perfectionism.
3.3🔒Risk-Based Arguments vs Authority-Based ArgumentsThe difference between effective and ineffective release blocking comes down to how you make your case.
3.4🔒Presenting Data: The Release Readiness AssessmentWhen recommending a release block, present a concise summary that decision-makers can evaluate quickly.
3.5🔒Escalation Patterns- Escalate the decision, not the blame. "We have a disagreement about release readiness and need someone with broader context to make the…
3.6🔒The Conditional Release CompromiseIn practice, most release decisions are not binary (ship / do not ship). The most common and productive outcome is a conditional release…
3.7🔒Post-Mortems: When You Did Not Block and Should HaveEvery QA engineer has this experience: you had doubts about a release, you did not push hard enough, and the release caused a production…
3.8🔒Real-World Scenarios with Example DialoguesContext: The team wants to deploy a major feature on Friday afternoon. You have found two medium-severity bugs and have not completed…
3.9🔒Exercises1. Write a release readiness assessment for your current project using the template from Section 3.3. Even if no release is imminent…
3.10🔒Career Translation- Developed and implemented a risk-based release readiness framework, replacing ad-hoc go/no-go decisions with data-driven assessments that…
3.11🔒Q&AInterview Depth CheckPrompt: You find two critical bugs in the checkout flow at 4 PM on the day of a planned release. The engineering manager says "we promised…