Series
Deciding what to test, what to skip, and whether to ship — when there's never enough time. Release readiness is judgement, not a passed-test-count. This series covers risk-based triage when the deadline is cut, a sign-off that actually changes the go/no-go call, and the lightweight plans people actually use.
// overview
Release readiness is a judgement call, not a passed-test count. This series is for the moment the deadline moves up, half your test time evaporates, and someone insists everything is critical — and you still have to decide whether to ship.
It works through the decisions in order: how to triage testing by risk when there's no time, how to run a sign-off that actually changes the go/no-go call instead of rubber-stamping it, and how to keep the planning lightweight enough that people actually use it.
The common thread is making the trade-offs visible and owned — what you tested, what you skipped, and who accepted the risk — so a release is a decision on the record, not a silent gamble.
// reading order
A test strategy is a short set of project-specific decisions, not a generic thirty-page document. Scope, risk, levels, automation split, data, ownership, and what "done" means.
How to prioritise testing when the timeline just got cut in half and everything is labelled critical.
A sign-off checklist short enough that people actually use it — and specific enough to catch the things that block releases.
The 40-page IEEE 829 test plan: written once at kickoff, opened twice during the project, abandoned after release. There's a single-page replacement that teams actually update.
A green suite confirms only what you thought to check. Readiness adds coverage-vs-change, accepted risk, observability, and non-functional signals.
Checklist
Template