Quality Is Everyone's Job. So Who Owns the Test Record?

A QA lead at a 40 person engineering org hears "quality is everyone's job" in nearly every retro. It is usually said kindly, as encouragement for developers to write better tests and take bugs personally. But six months later that same lead is the one standing in front of an auditor, or a new engineering director, trying to explain why a third of the test cases in the shared repository describe a checkout flow that was rewritten in March. Nobody lied. Nobody skipped a step on purpose. The record just quietly stopped being true, because everyone owned it, which in practice meant no one did. This post takes the "everyone's job" argument seriously, because it is largely right, and then draws the line that the slogan leaves out: doing the testing is everyone's job, maintaining the record of what was tested is somebody's.

The case for shared ownership, stated fairly

The argument for dissolving a standalone QA silo and spreading quality across the team is not a fad. It came from a real and repeated failure: a separate QA department that developers treated as a downstream checkpoint, so they wrote code fast and let someone else catch the bugs. That setup produced late discoveries, adversarial handoffs, and a QA team that became a bottleneck rather than a safeguard. Moving testing into the hands of the people building the feature fixed a lot of that. Developers who write and run their own tests catch mistakes earlier, understand the code they are testing, and do not treat a failing check as someone else's problem. This part of the argument deserves to be said plainly: it is correct, and this post is not an argument for restoring a separate department or reporting line.

The failure mode nobody names

Here is what actually happens when "everyone owns quality" is applied literally to the artefact, not just the activity. A team of eight engineers shares one test case repository. Each person adds cases for the feature they are shipping that sprint. Nobody is assigned to look at the whole repository, because that would sound like reintroducing a QA silo. Eighteen months in, the repository has 640 cases. Roughly a fifth of them reference a UI that was redesigned, a permission model that was replaced, or an API that returns a different error shape now. Nobody pruned them, because pruning was not anyone's job in particular. Nobody re-verified the older cases against the current build, for the same reason.

The rot is invisible in the ordinary course of work, because the team mostly runs the cases that were touched this sprint. It becomes visible all at once, usually in one of two ways:

• An external audit or a customer security review asks for evidence that a feature was tested, and the case on file describes a screen that no longer exists.
• A production incident traces back to a flow with a passing test case attached, and someone discovers the case has not actually reflected the real behavior for over a year.

Both are expensive moments to discover a maintenance problem. Both are avoidable, and the fix is not more people testing. The team already has plenty of people testing. The fix is one person accountable for whether the record of what was tested is still accurate.

The distinction that resolves it

Separate two things that "quality is everyone's job" usually blurs together. Performing the testing, meaning writing test cases, running them, and reporting the results, genuinely belongs to whoever is building the feature. Maintaining the record, meaning deciding what stays in the repository, what gets archived, what gets re-verified after a related change, and what the repository's structure even is, is a different kind of work. It is editorial, not executional. It does not require the owner to write most of the test cases themselves. It requires them to know the shape of the whole repository and to notice when a part of it has drifted from reality.

This is the same distinction a newsroom makes between reporters and an editor. Reporters do the reporting. An editor does not write every story, but somebody has to own the publication as a whole: what runs, what gets pulled, what needs a correction. Nobody argues that having an editor undermines the reporters' ownership of their own stories.

What the owner role actually involves, week to week

A reader should be able to take this section and write the job description. In a normal week, a test record owner does a handful of concrete things:

• Reviews new test cases added that week for duplication against existing cases, not for quality of writing.
• Flags cases tied to a feature that shipped a significant change, and routes them back to the engineer who touched that area for re-verification.
• Archives cases for retired features rather than leaving them live and misleadingly "passing."
• Keeps the repository's tagging and structure consistent enough that someone new to the team can find the cases for a given feature without asking around.
• Owns the answer, at any moment, to "which of our documented test cases can we still trust," which is the exact question an audit or an incident review asks.

None of this requires the owner to be more senior than the engineers contributing cases, and it does not require a title change. It requires that the responsibility be named, so that when the repository starts to drift, there is a specific person whose job it was to notice, rather than a diffuse "everyone" who each assumed someone else was watching.

Why the ownership needs to be named, not assumed

Teams resist naming this role because it sounds like undoing the shift toward shared responsibility. It is worth being direct about why that reaction, understandable as it is, misreads the proposal. Naming an owner for the artefact does not remove anyone's obligation to write and run good tests. It adds one narrow, specific obligation on top: someone is accountable for the health of the shared record, the same way someone is accountable for the health of a shared codebase's main branch even though everyone commits to it.

What to read next

If your team is close to naming this role, two things help immediately. The first is understanding what a well maintained test case repository actually looks like day to day, covered in our test case management guide. The second is understanding what "evidence" means when someone outside the team, an auditor or an enterprise buyer, asks for proof that testing happened, covered in our post on audit trails.