Quality Ownership

A defect reaches production. Whose failure is it?

Three answers are common. Two of them feel better than they work.

"QA's — they should have caught it." Creates a gate, and a gate creates a handoff. The builders optimise for passing the gate; the gate becomes the definition of quality; everything the gate does not check stops being anyone's concern. It also makes one group accountable for an outcome they cannot control, which is a reliable way to lose good people.

"Nobody's — defects are inevitable." True and useless. Defects are inevitable; this defect had a cause, and the cause is usually learnable.

"The team's." The only answer that produces a change in behaviour, because the team is the only entity with the authority to change the design, the tests, the process and the monitoring.

#What ownership looks like in practice

Not a value on a wall. Specific, observable behaviours.

A definition of done that includes testing.

Done means:
  - unit tests for the new branches
  - an integration test if it crosses a seam we do not own
  - an authorization test if it returns or mutates user data
  - the e2e journey still passes
  - it is observable in production (a log, a metric, or both)
  - somebody other than the author has used it

The last line is the cheapest and most skipped.

The person who wrote it is on call for it. Not as punishment — as a feedback loop. Nothing improves error handling faster than being woken by your own unhelpful error message.

Escaped defects trigger a question, not a blame.

This reached production. What would have caught it, and is that thing cheap enough to add?

Sometimes the answer is a unit test that takes four minutes to write. Sometimes it is "nothing reasonable — we accept this class of risk", which is a legitimate answer and belongs in the test strategy. What matters is that the question is asked every time and that the answer is acted on.

A red build is everybody's problem. Not the author's alone. A team that walks past a red main branch has already decided the suite does not matter, and everything downstream of that decision follows.

#The failure modes

The quality gate. A separate team signs off releases. Developers throw work over the wall; the wall becomes the specification. Everything the gate does not check degrades quietly.

The quality champion. One enthusiastic person carries the whole effort. It works while they are there and evaporates within a quarter of them leaving, because nothing was ever a team habit.

The quality metric. Coverage, defect counts, or test counts as a target. Goodhart's law applies immediately: the number improves and the software does not.

The quality initiative. A quarter of focused effort, a dashboard, and a return to previous behaviour once attention moves. Quality is a set of habits, and habits are not installed by initiatives.

#The signal worth watching

The most honest indicator of whether a team owns quality is not a metric. It is what happens in the first hour after a production defect.

A team that owns quality asks what would have caught it, and changes something — a test, a design, an alert, a line in the strategy.

A team that does not fixes the bug, closes the ticket, and moves on. The same class of defect returns in six weeks, and nobody connects the two.

#Testers in a team that owns quality

This is the part that gets lost. "The team owns quality" is frequently misread as "we do not need testers", which is a different claim and a wrong one.

A tester on a team that owns quality is not a gate. They are the person who is good at finding problems — a skill most developers have not been taught and cannot easily apply to their own work. They ask the question in refinement that saves three days. They explore the feature in ways nobody specified. They notice that the error is technically correct and completely unhelpful.

See SDET vs automation tester vs manual QA. The roles are real; what changes under team ownership is that they are inside the team rather than downstream of it.

#Starting from here

If the current arrangement is a gate, the transition is gradual and the order matters:

1. Move testers into the team. Same standups, same planning, same objectives. Nothing else changes yet.
2. Make the suite fast and trustworthy. Ownership is impossible if running the tests is painful and red does not mean broken — see flaky tests.
3. Put the results where developers are — the pull request, not a report. See test reporting.
4. Extend the definition of done to include tests, and enforce it in review.
5. Start asking the escaped-defect question, every time, without blame.
6. Only then consider removing the gate.

Removing the gate first, which is the usual instinct, gets you a team with no safety net and no habits yet. The gate is a symptom; take it away last.