Overview

Quality is not a phase between the code and the release. It is the property that decides what the next change costs, which makes it an economic concern before it is a moral one — and a team that discovers quality at the end has already paid for it at the beginning, at a worse rate.

That single sentence is what this hub is organised around. Everything below follows from it.

This hub is where quality assurance is decided, written down and run.

The three commitments

Each is a claim about how the work is organised, not about how anyone feels about quality.

Quality-driven development — the quality attributes are requirements with owners, not aspirations with advocates. A requirement nobody has to satisfy is a wish, and wishes are the reason “we’ll add tests later” appears in a plan that everyone signs.

Shift-left accountability — the deliberate word is accountability. Moving the tests earlier without moving the answerability just relocates the bottleneck and renames the queue. The person who can prevent a defect is the person who has to answer for it, which means the author of a change owns its tests and the test manager owns the strategy rather than the backlog of everyone else’s bugs.

Testing in production is an option — a real one, with entry conditions. Some properties of a system are only observable under real traffic, real data and real scale; denying that buys a staging environment that lies convincingly. It is an option, not a default, and the page says what has to be true first.

A fourth idea runs underneath all three: risk-based testing. There is never enough time to test everything, so the only question that matters is what you are choosing not to test, and whether that choice was made deliberately or by running out of Friday.

The two questions

Every campaign and every typology serves one of two questions, and a team is only covered when it is asking both.

Have we built the right thing? — correctness and completeness against a need. Answered from outside the software, by the people who will live with it: acceptance criteria, exploratory sessions, usability, and what production actually shows.

Have we built the thing right? — the properties the software has to hold regardless of what it does: it must be fast enough, resilient enough, secure enough, usable by everyone, and cheap enough to change. Answered from inside, mostly by the people who wrote it.

Neither survives alone. The right thing built wrong dies of its next release; the thing built right on the wrong thing is deleted. The strategy follows both questions through every level, from a unit test to a canary.

How the documentation is organised

The four sections are four different questions, and keeping them apart is what stops a strategy document from becoming a tool list.

Section	Answers
Typologies	What kind of test is this, and what can it catch that nothing else can?
Topologies	Where does it run — in-process, against a container, in an environment, in production?
Guidelines	How is it written so that it is still worth keeping in a year?
Tooling	With what, and why that one rather than the other three?

The distinction between the first two is the one most often collapsed, and the collapse is expensive: “an integration test” names a typology, and says nothing about whether it runs against an in-process fake, a Testcontainer, a shared environment or a live system — which is the part that decides what it costs and what it proves.

The rest of the hub

• The strategy — the whole thing on one page: what is tested, at which level, where, with what, and who answers.
• Research — an open investigation into a domain-specific language for writing performance tests. Not a recommendation yet; the page is honest about which parts are still questions.
• MCP — the four model-driven tools that would carry the automatable half. Described, not built.
• Campaigns — the seven campaigns that actually run, each with a scope, an owner and an exit condition.
• Academy — seven learning paths through all of it.

What is here today

This portal is a scaffold, and it says so where it matters. The documentation sections above are written; the MCP servers they describe are not built, the Academy lessons are not recorded, the performance DSL is a research direction rather than a shipping tool, and the campaign results service the Campaigns page links to is not deployed. Each says so on its own page.

The neighbouring hubs are real: the development practices this strategy hangs off are dev-hub, and the contracts that contract tests are written against are api-hub.