Test Architecture Strategy
A written decision about which risks are covered by which kind of test, at what scope, run at what point, and which risks are accepted.
Most organisations have a test process and no test strategy, which is why suites grow by accretion — every incident adds a test, nothing is ever removed, and after four years the suite takes ninety minutes and nobody can say what it protects.
A strategy is a mapping from risk to instrument. Start from what would actually hurt: silent wrong financial calculations, data loss, a security boundary failing open, an outage of a specific journey, a regulatory breach. For each, name the test type and scope that could detect it, and where it runs. Then, deliberately, name what is not covered and why — usually because detection in production plus fast rollback is cheaper than prevention.
This produces different answers for different systems, which is the point. A pricing engine warrants property-based and mutation testing on its calculation core. A content site warrants visual regression and performance budgets. Applying the same suite template to both wastes effort in one place and leaves a hole in the other.
The artifact is short: a page per system, reviewed when the risk profile changes. Its value is that it makes removing a test a decision rather than a taboo.