Principles

A principle is not a practice. A practice is a ritual with participants and an output; a principle is what someone brings to it, and it is what decides whether the ritual produces anything.

These four are separated out because they are the parts of the strategy that survive a change of tooling. Replace every tool in the tooling section and the strategy still holds; abandon one of these and it does not.

Principle	The claim
Quality-driven development	Quality is what the next change costs, so it is an economic property and it belongs in the requirements.
Shift-left accountability	Moving tests earlier without moving answerability relocates the bottleneck. Move the answerability.
Risk-based testing	There is never enough time. The only real question is what you choose not to test, and whether you chose it.
Testing in production	Some properties only exist under real traffic. An option with entry conditions, not a confession.

They are a chain, not a list

They build on each other, and the order is the order of dependency.

Quality-driven development says the quality attributes are requirements. That raises the question of who satisfies them, which is what shift-left accountability answers: the person who can prevent the defect. That person immediately runs out of time, which is what risk-based testing is for — an explicit decision about what goes untested rather than an implicit one. And having made that decision honestly, a team discovers a residue of properties that genuinely cannot be checked before release, which is where testing in production stops being a euphemism and becomes the remaining option.

Skip one and the next collapses. A team that shifts tests left without accountability produces developers writing tests they do not believe in. A team that accepts risk without a risk model calls whatever it ran out of time for “low priority”. A team that tests in production without the first three has not adopted a technique — it has stopped testing and found a name for it.