Main idea

When QA is the last line of defense before production, it tests what should have been thought through, clarified, automated or avoided earlier. It arrives after the decisions have been made, with blocking or letting through as its only means of action. It is the place where developers drop off their quality responsibility, and where the organization outsources its defects.

The same job, placed elsewhere, does something else: it defines the quality criteria, the testing policies, the shipping standards, the acceptable regression thresholds, the risks to cover, the areas of the product to secure, what has to be automated, and the signals that say whether a team is shipping better or worse. It does not take over developers' responsibility — it builds the framework that makes it practical, measurable and sustainable over time.

The difference is not a matter of skill or seriousness: it is the position in the chain that decides whether the function frames or catches up.

Why it matters

This reframes an organizational question usually posed in terms of headcount — how many testers for how many developers — as a question of position: at what moment does QA weigh in on a decision.

It also gives a readable sign of drift: a QA whose activity is measured in defects found before go-live occupies the place of a safety net, whatever its job title.

Nuances and limits

A final check is still necessary, and some constraints — certification, contractual obligation, audit — formally require it. What is at issue is not its existence but its status as the only quality mechanism.

And moving QA toward quality policy presupposes that it has a hold on upstream decisions. Without a mandate, it produces standards nobody applies, which puts it back at the end of the chain with one more document.

Open questions

• Can one and the same team hold both upstream framing and final verification, or does the second always take precedence over the first?