QA operating model for a 15-engineer team: the one-pager

Process for a 15-person team should fit on one page, or it won’t be followed. The goal isn’t a QA bureaucracy, it’s a few clear defaults so quality is everyone’s job without anyone having to think about it. Here’s the whole operating model, small enough to paste in your team wiki.

Roles: who owns what

You don’t need a QA department. You need clear ownership:

Engineers own their tests. Unit and integration tests ship with the feature, in the same PR. “Done” includes “tested.”
The reviewer owns the gate. Code review also checks: are there tests for the risky paths? Does the eval suite still pass?
One release owner signs off. A named person (rotating is fine) makes the “safe to ship” call against written criteria, not a vibe the room has.

That’s it. Three roles, no new org chart.

Rituals that earn their place

Keep only the meetings that change a decision:

Triage, 15 minutes, twice a week. New bugs get a severity and an owner. That’s the whole meeting.
A written release note per release, not a meeting. What shipped, what’s risky, who signed off.
A quarterly quality review, 1 hour. Where is risk moving, what to automate next, what to retire.

Kill standing “QA status” meetings. If it can be a written update, it should be.

Bug triage in three buckets

Don’t build a Jira swamp with nine priority levels. Three buckets:

Now, broken critical path or data/security risk. Stop and fix.
Next, real bug, not on fire. Goes into the current cycle.
Later / won’t, cosmetic or rare. Logged honestly, not pretended into the backlog forever.

Every bug gets a bucket within two days of arriving, or the backlog stops meaning anything.

Release sign-off and quality gates

A release ships when the gates are green and the owner signs. Written down so it’s not personal:

Release checklist (the gate):
[ ] Smoke suite green (blocking)
[ ] Eval suite green - no regression vs baseline
[ ] No open "Now" bugs on the shipping paths
[ ] Cost/latency guardrails green
[ ] Release owner sign-off recorded

The point of writing it down is that enforcing it later isn’t a confrontation, it’s just the rule everyone already agreed to.

The loop that makes it improve

One habit compounds more than any other: every incident becomes a regression test. When something breaks in production, the fix isn’t done until there’s a test that would have caught it. Do that consistently and your coverage grows along the exact shape of your real failures, and the same incident never bills you twice.

How it scales

At 15 engineers this one page is enough. At 30+, the release owner role likely becomes a part-time-then-full-time QA function, triage may split by area, and the eval suite grows its own ownership. But the bones stay the same, you add weight to a model that already works, instead of inventing process under pressure.

This one-pager is a standard deliverable of a QA Foundation Sprint, tailored to how your team actually ships, and keeping it alive (sign-offs, triage, the incident loop) is what a Fractional QA Lead does week to week. The process is only worth the paper if someone owns it.