QA Didn't Pick the Release Date

The release was Thursday. QA got the build Wednesday at 4:10 p.m. By Thursday at noon there were six open bugs, two of them in the payment step, and the sales lead asked, in the channel everyone reads, why QA was "blocking" the date. The date had been promised to a customer in a call three weeks earlier. QA wasn't in the call. The engineer who knew the payment step was half done wasn't in the call either. The date was a sentence that felt good at the time.

I've watched this scene enough times that I don't find it confusing anymore. I do find the retro afterward usually useless, because the team spends it on the bugs and not on the sentence.

The date was never a QA output

QA can tell you what they found in the hours they had. They can't tell you a date is safe if the date was chosen before the scope sat still. On that Thursday, two of the six bugs were real and should have held the release. The other four were rough edges the customer would have lived with. The argument in the channel treated all six as one crime, committed by the people who filed them. Filing is not slipping. Promising Thursday when Wednesday's build is the first time anyone outside the feature branch has seen it, that's the slip. It happened in a call, with a smile, weeks ago.

Blame sticks to QA because they're holding the paper at the end. The bugs have their names on them. The promise doesn't have a ticket. Invisible decisions don't show up in the retro unless someone drags them in.

What the hour before the release is actually for

There's a useful job in that last day, and it isn't "approve the date." It's a risk note. We started writing one in four lines, in the release channel, before anyone asked for a verdict.

What we tested. What we didn't get to. What is broken in a way that loses money or data. What is ugly and can ship. A name who accepts the ugly.

On that payment release, the note would have said: payment step failed twice on a retry, don't ship that; the alignment on the receipt is off, ship it if you must. The sales lead can still override. The override is now a decision with a witness, not a vibe that QA "couldn't finish." When the retry bug hit staging again the following week, nobody had to reconstruct who knew. The note was there. The person who said ship anyway was there too.

This only works if the note is allowed to be incomplete. If leadership wants a blessing, they'll push until they get one, and the blessing will be a lie. Ask for the four lines. Don't ask for a signature that means "I guarantee Thursday."

The retro question to swap in

The usual retro asks why the bugs weren't found sooner. That's a fair question for a bug that had a week to be found. It's a dodge when the build arrived at 4:10. The question that changes the next date is: who was in the room when Thursday got promised, and what did they think was still unfinished?

Write the names down. Not to humiliate the sales lead. To see the pattern. On this team, three releases in a row had been dated in a customer call with no engineer and no QA present. Once that was on the retro board, in ink, it was harder to call it a testing failure. The fix they actually adopted was dull. A date isn't a date until the person building the thing has said what still isn't done, in the same conversation, or in a note attached before the call ends. If the call can't wait, the date is a wish, and wishes don't go in the customer email.

QA's part of that fix is to show up to the conversation where dates are born, not only to the one where dates die. If they aren't invited, the retro is the place to say so. Skipping that sentence because it feels political is how you stay the person who "blocked" Thursday.

Stop collecting bugs that aren't the argument

The other habit that feeds the blame is a last-day list with no rank. Six bugs looks like a crisis. Two bugs and a shrug about the receipt looks like judgment. QA has to do that ranking out loud, before someone else ranks it as "QA being difficult." Severity is the job. A list of everything that annoyed you is how you hand the other side a poster.

I'd rather defend two hold-the-line bugs than apologize for six. The receipt alignment can be a card in the next sprint. It does not need to stand next to a broken retry as if they were siblings.

Say the quiet part in the notes

If you take one thing into the next retro, make it this: the release date is a commitment made by the people who had the authority to make it. QA informs that commitment when they're given time and a build. They don't backdate their signature onto a call they missed. Write who promised, what was unfinished, and which bugs were worth slipping for. The payment retry was worth it. The receipt wasn't. The channel doesn't need a villain. It needs that distinction, or you'll run Thursday the same way next month and act surprised at 4:10 again.