In this guide 6 sections
A release is ready when it meets exit criteria written before testing began, including defects by severity, a passed regression run, checked payments, a tested rollback and one approver. One failed line makes it no go. The calendar does not decide.
Write the exit criteria before the first test runs
Bad launches start when nobody agreed what ready meant. By the final week the date is fixed, the client is waiting and every open bug starts to look small, so the argument is lost before it begins. Write the rules first. Do it while nothing is at stake.
Put them on one page and have the product owner, the lead developer and the tester all initial it beside the build number being judged. Every line must be answerable with yes or no. “Quality is acceptable” is useless. “No open Severity 1 or Severity 2 defects” can be checked in minutes by anyone holding the ticket list, whereas a vague line invites a debate at midnight.
- Defect ceiling for each severity
- Regression suite result on the release build
- Payment, refund and tax checks passed
- Data migration counts reconciled
- Rollback rehearsed on a copy
- Named approver and backup approver
Count defects by severity, not by number
Forty cosmetic bugs are less dangerous than one wrong invoice total, yet a raw count in the tracker treats them as forty problems against one. Sort every open ticket into bands. Blocks the main task. Breaks a task but has a workaround. Wrong but harmless. Cosmetic.
Then set the ceiling for each band. Zero in the first band is normal, and the second band is allowed only when the workaround is written down and the support desk has read it. Ask who accepted each deferral. A defect nobody owns is a defect nobody fixes after launch, no matter how politely it was parked in the backlog during the last week before the deadline.
Check the things that cost money or lose data
Some checks outrank the rest. Run a card payment in the gateway sandbox, then a refund, then a declined card, and compare the order record, ledger entry and confirmation email for the amount. Click the pay button twice. It must not charge twice.
For data, compare record counts before and after migration, then spot check a dozen customers by hand against the old system, including long names and blank phone fields. Try editing an order number in the address bar to open somebody else’s order, because that failure makes the news and a misaligned button does not.
- Sandbox payment, refund and declined card
- Totals, tax lines and rounding on sample orders
- Imported record counts against the source file
- Access to another user’s record is refused
- Backups restore on a clean server
Rehearse the rollback and name the approver
A rollback plan never run is a hope. Restore last night’s backup onto a spare server, switch the new release off and time every step, so the plan has real numbers behind it. Write down who flips the switch, who tells customers and what happens to orders placed during the failed window, before the night of launch.
Then name one person who says go. Committees produce shrugs. The approver reads the exit page, hears the tester’s summary and signs, with a second person named in case of illness or leave. Without a name the release goes out simply because nobody stopped it, and nobody can say afterwards who was meant to decide.
Hold the meeting and record the verdict
Meet for twenty minutes the day before. The tester reads each criterion aloud and gives the evidence, and anything marked no stays no until the evidence changes, however late the hour or loud the client. Arguments about whether a failed line really matters belong in the earlier criteria workshop, not in this room, where the only task is checking evidence.
Write down the verdict, build number and time. A no go gets a list of changes and a review date, while a go with accepted risks attaches the deferred defects to the release note. Start the next one from this page.
Release go or no go sheet
The five rows cover defects by severity, regression result, payment and data checks, rollback rehearsal and the approver, with every row tied to the same build number. Columns are criterion, required result, actual result and pass or fail, followed at the bottom by a signature box for the approver and a box for accepted deferrals.
Open a blank worksheet to printQuestions owners ask
Who should approve a release?
One named person with the authority to delay it, usually the product owner, because the tester advises and the developer explains risks but neither should sign. Name a backup. A sick day should never force a guess.
Can we release with open bugs?
Yes, if they are minor with a written workaround and an owner, but anything that blocks the main task, corrupts data or touches payments should stop the launch.
What if the deadline cannot move?
Cut scope instead of cutting checks. Ship the finished features behind a switch, hold back the unfinished one and keep every exit criterion, because a smaller release that passes beats one that does not.
How soon before launch should we decide?
Decide the day before, with a code freeze from that point, and tell everyone that any change after the sheet is signed restarts the regression run. Publish that rule at kickoff.