A Bug Reached Production: How QA Gets Through the Postmortem Without Becoming the Culprit

Thursday evening. A thread is growing in the support chat: payments are failing for part of the users. Ten minutes later one of the managers writes in the general channel: “Did QA even test this?” And here it is, the moment this article was written for. In that second the tester is pulled in one of two directions: start proving they did test it, or silently decide that yes, it’s their fault, they should have done better. Both paths lead nowhere. The first damages your relationship with the team and changes nothing in the process. The second damages you and also changes nothing in the process.

There is a third path, and it has a name: the blameless postmortem. Below is why it works, how to take part in it from the QA side, and what to do if in your company the review still looks like a tribunal.

Why “who is to blame” is the wrong question

Let’s start with an uncomfortable thought: a bug in production is almost never one person’s failure. For a defect to reach a user it had to pass through requirements, code, code review, automated tests, manual testing, staging, the release process and monitoring. Every layer could have caught it, none did. This is James Reason’s Swiss cheese model: an incident happens when the holes in several layers of defence line up. Richard Cook, in the classic essay How Complex Systems Fail, puts it even harder: a catastrophe in a complex system never has a single root cause, it requires several failures at once, and the search for “the root” is a social need rather than a technical truth.

QA is one layer in that chain. An important one, but one. When a team names the tester as the culprit, it gets quick emotional relief and zero information about why the other seven layers also let the bug through.

The second argument is even more practical. Google, in the postmortem culture chapter of the SRE book, explains why they go blameless: if mistakes are punished, people stop talking about them. An engineer who knows that an honest “I pressed the wrong button” will earn a reprimand will stay silent next time, and the team loses its only source of data about how the system actually works. John Allspaw, who introduced blameless postmortems at Etsy, says it directly: a culture of blame gives a company less information and more incidents.

For QA this means one simple thing: your job at the review is neither to defend nor to repent. Your job is to bring the maximum of facts about how the defect passed through testing, because without those facts the process cannot be fixed.

The first hours: what to do while it is still burning

The postmortem comes later. While the incident is ongoing the tester has work to do, and it is more useful than any explanation in chat.

Don’t defend yourself in the general channel. The line “I checked this, it worked for me” at the moment users can’t pay sounds like a refusal of responsibility, even if it is the plain truth. Everything you want to say about coverage, say later and with facts.
Localise. The most valuable role of QA in an incident is narrowing the problem down fast: does it reproduce, on which platforms, versions, countries, for which user segments. “Fails only on Android 14 when paying via Google Pay, iOS is fine” saves developers an hour of searching.
Assess the scope and find a workaround. How many users are affected, is there a workaround for support, do we need to roll back or can we live until the hotfix. That is what the manager will ask first.
Test the hotfix properly. Under the pressure of “ship it faster” this is exactly where the second incident is born. Smoke on the affected scenario plus the neighbouring scenarios the fix touches. If there is no time for regression, record in writing what exactly was not checked.
Collect facts for the future review while they are fresh. When the code was merged, what the test plan was, what part of it ran, on which environment, with which data, what the requirements said. A week later half of this is forgotten, and everyone’s memory conveniently bends in their own favour.

A separate word about the phrase to use instead of “I tested it”. When you are asked in the moment anyway, a three-part formula works: what was covered, what wasn’t, why. “Payment was checked on iOS and on Android 13 with a test card. Google Pay on Android 14 was not checked: it wasn’t in the test plan, and the team has no devices with 14.” That is neither an excuse nor a confession, it is data. Data can be worked with, emotion cannot.

How a blameless postmortem is structured

The format differs slightly between companies, but the skeleton is the same. Good open templates come from Atlassian and PagerDuty, and the deepest modern guide is Howie from the Jeli team. The main blocks:

Impact. What broke, for whom, for how long, in money or users. Without this you can’t tell whether the review is worth two hours of ten people.
Timeline. A factual chronology with timestamps: when merged, when deployed, first signal, detected, fixed. Events only, no interpretation.
Contributing factors. Not a single “root cause” but a list of factors, each of which contributed. This is where all the honesty of the review lives.
What went well. What helped detect and fix quickly. Not for comfort, but so you don’t accidentally break what works.
Action items. Concrete changes with an owner and a deadline. A separate section on them below.

The format has two rules, and both matter more than the template.

First: a ban on counterfactuals. Phrases like “should have”, “if QA had run the regression”, “must have noticed” describe an imaginary world, not the one in which the incident happened. They don’t explain why a reasonable person at that moment with that information did what they did. This is hindsight bias: once the outcome is known, it seems obvious in advance. At the review it is more useful to ask “what did you see at that moment and why did it look normal”.

Second: be careful with the five whys. The method is popular, but in complex systems it almost always ends at a person: “why is the bug in production? because it wasn’t checked; why wasn’t it checked? because the tester didn’t think of it”. Allspaw in The Infinite Hows suggests asking “how” instead of a linear “why”: how was the system arranged so that this became possible? “How” gives a branching picture and leads away from hunting for a scapegoat.

What QA should say at the review

The tester has a unique position at a postmortem: they are the only one who knows what the defect looked like from the verification side. That knowledge has to be brought as facts, and almost every fact turns into a systemic factor.

The scenario wasn’t in the requirements. Then the factor is not “QA didn’t think of it” but “requirements don’t describe payment edge cases, and there is no stage where they get clarified”. An action item about the requirements process, not about attentiveness.
There was no environment or data. No device with Android 14, no test account with a real card, no production-like configuration. A factor about test infrastructure.
Regression was cut for time. Someone decided to ship without a full run. That is a decision, it has an author and a reason, and it belongs in the timeline as a fact, not as an accusation. If QA warned in writing, that is a fact too.
The test existed but didn’t work. The automated test was flaky and got disabled, or it checked a mock instead of the real integration. A factor about test quality.
Staging differed from production. A different payment provider, a different feature flag, different data. A factor about environment parity.
Monitoring didn’t catch it. Users noticed the problem, not an alert. A factor about observability, and it is not about QA at all.

Notice: in every point the factor is phrased so that it can be fixed by changing the system. “The tester will be more careful” cannot be fixed, it is not a system, it is a hope.

Action items that change something

Half of all postmortems end with items like “be more careful”, “improve communication”, “add to the checklist”. A month later nobody remembers them. A good action item passes three checks: it is concrete, it has one owner, and you can objectively say whether it is done.

Bad and good pairs for our payment example:

“Test payments more thoroughly” versus “an automated test for payment via Google Pay in CI, owner X, by the end of the sprint”.
“Don’t forget about new Android versions” versus “Definition of Done for mobile features includes a run on the last two major versions, buy a device with Android 14”.
“Take regression more seriously” versus “a release without full regression requires an explicit lead decision recorded in the release ticket”.
“React faster” versus “an alert when payment conversion drops below a threshold, the on-call gets a push”.
“Write better requirements” versus “the feature template has a mandatory section on platform constraints and negative scenarios”.

Note that of the five good items only two are about testing. The rest are about monitoring, the release process and requirements. That is how it should be: if after the review all action items land on QA, it is a sure sign that the team was looking for a culprit, not for causes.

If your team still hunts for a culprit

Not every company has the SRE book on the shelf. Sometimes the review really does look like “who missed it”. What you can do without changing jobs:

Write the postmortem first. Whoever writes the document sets the frame. If you come to the meeting with a ready factual timeline and a list of factors, the discussion follows your structure, not “so who tested this”.
Propose a format. Bring the Atlassian or PagerDuty template and say “let’s try going through it with this scheme”. Few people refuse someone else’s proven process, especially when it saves time.
Translate accusations into facts out loud. “You should have caught this” becomes “let’s record it: the Google Pay on Android 14 scenario wasn’t in the test plan. Why wasn’t it there?” Calmly, without defending. One or two such translations change the tone of the meeting.
Keep written traces. The test plan, the list of what wasn’t checked, risk warnings before release. Not to point fingers later, but so the review runs on documents, not on memory.
Escalate through your lead. If the blame culture is systemic, that is a conversation for a 1-1, best framed as “problem, options, what I’m asking for”. How to prepare such conversations is covered in our article on 1-1s for QA.

And an honest final point: if after several attempts every incident still ends with a hunt for a scapegoat, and the scapegoat is QA time after time, that is information about the company, not about you. It will come in handy too, including when choosing your next job.

How not to eat yourself alive

We’ve talked about the team, now about you. A missed bug hits a tester’s self-esteem especially hard, because finding bugs is literally your job. A few anchors.

Edsger Dijkstra put it back in 1970: testing can show the presence of bugs, but never their absence. That is not an excuse, it is mathematics. No test plan covers an infinite state space. The question is never whether you will miss a bug, but which bugs you choose to catch first and how the system insures the rest.

Separate two questions your brain glues into one. “What could I have done differently” is a working question, it is answered with facts, and the answer goes into action items. “I am a bad tester” is not a question but a conclusion, and it is drawn from a single incident, which is statistically meaningless. The first question is worth working on, the second is not.

A practice that helps personally: keep your own log of missed bugs. Date, what the bug was, why it got through, what would have caught it. Six months later patterns show up in that log: for example, you systematically underestimate platform differences or trust staging too much. A pattern is something you can actually fix. A single incident is noise.

And the last thing. If an incident won’t let go of you for weeks, you are afraid to give sign-off and every release feels like waiting for a blow, that is no longer about one bug. We wrote about it in detail in our piece on burnout in QA, including what to ask your team lead for.

QA checklist for a postmortem

During the incident: localise, assess the scope, find a workaround, test the hotfix. Don’t defend yourself in the general channel.
Record the facts while they are hot: what was covered, what wasn’t, on which environment, with which data, what the requirements said.
Answer “did you test it?” with the formula: what was checked, what wasn’t, why.
Come to the review with a ready factual timeline, no interpretation.
Phrase every fact from the testing side as a systemic factor that can be changed.
Catch counterfactuals (“should have”) and turn them into “what was visible at that moment”.
Make sure action items are concrete, with an owner and a deadline.
If all action items landed on QA, say so out loud: it means not everything was examined.
Don’t sign up for “be more careful”. That is not an action.
Write the incident into your personal log and look at patterns six months later, not at the single case.

A bug in production is not an exam the tester failed. It is the most expensive and the most honest test of your process, and its results have already been paid for by your users. The only way not to pay for them twice is to review without hunting for a culprit and to fix the system, not the person.