Module 1 · Software & QA foundations

Quality Culture

By the Mutqan Soft QA team · · 17 min · Beginner

Quality culture is the set of shared habits and expectations that decides how a team treats quality day to day: who feels responsible for it, how early problems are raised, and what happens after something goes wrong. In a strong quality culture, quality is a whole-team responsibility, and failures are treated as information to learn from rather than as a reason to blame someone.

For example, a tester reports that the new payment flow was never tried on a slow network. One team replies "no time, ship it", and the risk never reaches the release decision; another asks what could go wrong and agrees on a one-hour check. The skills are the same; the culture decides whether the information is used.

Why it matters

Testing produces information, and information reduces risk only when people act on it. Where bad news is unwelcome and defects are counted against people, problems tend to stay hidden until customers find them, and the later a defect is found, the more it costs in rework, incidents and lost trust.

For a tester, culture shapes the job itself. Where quality is "QA’s job", the tester is a gatekeeper at the end of the sprint, short of time and blamed for every escaped defect. Where the team owns quality, the tester starts at refinement and helps prevent defects, not only find them.

The whole-team approach

The lesson on testing roles and responsibilities introduced the whole-team approach of the ISTQB Foundation syllabus v4.0. The syllabus also explains why it works: team members share a workspace, physical or virtual, which makes communication easy; the approach improves team dynamics, communication and collaboration, and lets the team use all its different skills for the benefit of the project.

By working closely with business representatives and developers, testers pass testing knowledge to the rest of the team and influence how the product is built.

Quality work is then spread across roles and the whole lifecycle:

  • Before development: the product owner, a developer and a tester agree on examples and acceptance criteria for each story, which some teams call a "three amigos" session.
  • In planning: the team rates product risks together and agrees how deeply to test each one.
  • After release: support and operations share incidents and complaints, which become new test ideas.

Try it: Acceptance Criteria Generator Try it: Risk-Based Test Generator

Psychological safety and blameless postmortems

A team can share responsibility for quality only if people feel able to raise problems. The researcher Amy Edmondson calls this psychological safety: a belief shared by a team that it is safe to take interpersonal risks, such as asking a basic question, admitting a mistake or disagreeing with someone senior. Testers need it because testing produces bad news by design, and they help build it by reporting facts, not judgements.

Safety is tested hardest when a significant failure reaches users. Many teams then write a postmortem, which Google’s Site Reliability Engineering book describes as a written record of an incident, its impact, the actions taken to mitigate or resolve it, its root causes and the follow-up actions that prevent it from recurring. A blameless postmortem assumes everyone acted in good faith with the information they had, and looks for contributing causes in systems and processes, not for a person to punish. A tester usually helps with three parts:

  • Timeline: when the failure started, how and when it was detected, and when it was resolved.
  • Causes: following the chain from error to defect to failure, ask why the error was possible and why the defect was not detected earlier.
  • Actions: specific changes, each with an owner and a due date, followed until they are done.

Signals of a healthy quality culture

Culture shows in everyday practice. The sociologist Ron Westrum classified organisations by how they handle information: in pathological cultures messengers are punished and failure leads to scapegoating; in bureaucratic ones messengers are neglected; in generative ones messengers are trained and failure leads to inquiry. DORA’s research on software delivery uses this model. Testers are often the messengers, so look for these signals:

  • Testers take part in refinement, and acceptance criteria are reviewed before development starts.
  • A shared Definition of Done includes testing, which is not dropped when time runs short. The 2020 Scrum Guide defines it as a formal description of the state of the Increment when it meets the quality measures required for the product.
  • A failing build or test is investigated first, not ignored or re-run until it passes.
  • Metrics are used to learn, never to rank people: no bug-count targets, no defect counts per developer.
  • Retrospectives end with actions that actually happen, not the same complaints every sprint; in Scrum, the Sprint Retrospective exists to plan ways to increase quality and effectiveness.
Weak and strong quality cultures differ in who owns quality, how bad news is received and what follows an escaped defect: blame and more sign-offs, or a blameless review with owned actions. Conceptual model

Weak quality cultureWestrum: pathological or bureaucratic

Quality is the testers’ job

Testers join:
After development, to check the build
Bad news:
Messengers punished or neglected; untested risks go unreported
After an escaped defect:
Who missed it? More sign-offs
Root cause:
A person, or "human error"
Definition of Done:
Testing is dropped when time runs short
Failing build or test:
Ignored, or re-run until it passes
Metrics:
Rank people: bug-count targets, defects per developer
Retrospectives:
The same complaints every sprint

Strong quality cultureWestrum: generative

Quality is the whole team’s job

Testers join:
In refinement, before code exists
Bad news:
Messengers trained; risks reach the release decision
After an escaped defect:
Blameless postmortem with owned, dated actions
Root cause:
Why the error was possible and why it was not detected earlier
Definition of Done:
Shared, and includes testing
Failing build or test:
Investigated first
Metrics:
Used to learn
Retrospectives:
Actions that actually happen

Signals, not a score: most teams show some of each column.

Worked example: one escaped defect, two cultures

After a release, customers using the Arabic interface cannot finish checkout: in the right-to-left layout the "Pay now" button is pushed off the screen on small phones. Support reports it two hours later and the team rolls back.

In team A, the manager asks in the group chat who tested it, and a new rule follows: "QA signs off every release". Nothing else changes, and next sprint people raise fewer doubts, because doubts now lead to blame.

Team B holds a blameless postmortem. The timeline shows that customers, not the team, detected the failure. Every contributing cause gets an action, and the tester owns one too:

  • Designs and acceptance criteria covered only English. Action: add right-to-left layout to the refinement checklist (product owner and tester).
  • The story was merged on the sprint’s last afternoon. Action: limit work in progress so stories finish earlier (whole team).
  • No regression check covered right-to-left layout on small screens. Action: add one (tester and developer).
  • No alert fired when completed checkouts dropped for one language. Action: add monitoring (operations).

Try it: Regression Scenario Generator

Common mistakes

  • Using defect counts to rate people, such as bugs found per tester or defects per developer: people start arguing about the numbers or hiding problems instead of fixing causes.
  • Reacting to an escaped defect by asking "who tested this?": people then raise fewer doubts and hide mistakes, so the next problem surfaces even later.
  • Treating "blameless" as "no follow-up": a postmortem without owned, dated actions changes nothing.
  • Naming a person, or "human error", as the root cause. That is where the questions start, not where they end.
  • Staying silent about an untested risk to avoid conflict, so the release decision is made without it.

The QA perspective

Culture changes through small, repeated practices, not announcements. Ask about risks and examples in refinement, report defects as facts about the product, and when something escapes, help build the postmortem timeline and propose at least one action for testing itself, such as a missing regression check.

Record the risks you raised and what was decided, what was not tested and why, and the status of follow-up actions. In job interviews, ask questions that reveal the culture: "What changed after your last postmortem?" and "What happens when a tester says a release is not ready?"

Practice exercise

Rewrite an incident note in blameless form

Your task

The incident note below was posted in a team chat after a failed release. Rewrite it as a short blameless postmortem: summary, impact, timeline, contributing causes, and follow-up actions with an owner role. Then name two signals of a weak quality culture in the note, and one question you would ask in the retrospective. You can draft it in Markdown and preview it with the Markdown Formatter tool.

Material
Incident note, posted in the team chat on Monday

Omar merged the coupon change at 17:40 on Thursday without telling QA.
Lina tested it for 20 minutes and missed that expired coupons still work.
Customers used expired coupons all weekend. Finance found it on Monday.
QA has missed things before. From now on QA signs off every release,
and Omar needs a manager’s approval for every change.
Steps
  1. Remove names and judgements; keep what happened, when and to whom.
  2. For each fact, ask why the error was possible and why it was not detected earlier.
  3. Turn each cause into one action with an owner role.
Show the model answer
Model answer

Summary: a coupon rule change, merged at 17:40 on Thursday and released before the weekend, accepted expired coupons. A finance check detected the problem on Monday.

Impact: weekend orders received discounts the business had not intended. Detection came from a finance check, not from tests or monitoring.

Timeline: Thursday 17:40, the change is merged; about 20 minutes of testing follow and the change is released; over the weekend, orders accept expired coupons; Monday, finance detects the problem. Take the exact release and fix times from the deployment log.

Contributing causes, to confirm in the review: a late merge with no agreed time for testing; acceptance criteria silent on expired coupons; no expiry check in the regression suite; no monitoring of coupon validity on orders.

Actions: coupon expiry rules in the acceptance criteria (product owner and tester); a merge cut-off before each release (team); expired, not-yet-valid and valid coupon cases in the regression suite (tester and developer); an alert on orders with an expired coupon (operations).

Culture signals: people are named and blamed for a system failure, and the remedy is more gatekeeping instead of earlier collaboration. Retrospective question: "What would have helped any of us catch this before customers did?"

Frequently asked questions

How can a team tell whether its quality culture is improving?

Look at behaviour and trends, not at one number. Useful signals: how many defects reach users and who detected them, the team or customers; how long a failing build stays unfixed; and how many postmortem and retrospective actions are actually completed. Avoid metrics that rank people, such as bug-count targets or defects per developer: they reward hiding problems and arguing about counts instead of fixing causes.

Is a blameless postmortem the same as a retrospective?

No. A postmortem analyses one specific incident, usually soon after it, and produces a written record with actions. A retrospective is a regular meeting about how the team worked over a period, such as a sprint. Postmortem actions are often followed up in retrospectives.

What can I do if my team blames people for defects?

Start with your own behaviour: report facts, not culprits, and describe causes in terms of process and systems. Propose a blameless format for the next incident review, with a timeline and owned actions, and ask in the retrospective what would have helped anyone catch the problem earlier. Change is gradual; one well-run review often convinces more than an argument.

Does psychological safety mean nobody is criticised?

No. It means people can raise problems, ask questions and admit mistakes without being humiliated or punished. Work is still reviewed critically and standards stay high; the criticism is aimed at the work and the process, not at the person.

References

Tools

Practise with Mutqan tools

Risk-Based Test Generator

Score features by likelihood and impact, then generate a prioritised risk-based test plan.

Test Design

Markdown Formatter

Normalise Markdown formatting (headings, lists, tables, emphasis) and preview the rendered result.

Formatting

Go deeper

Your progress on this topic

Part of the QA Roadmap