What would you include in a test strategy for a Salesforce programme?

I structure it by who is testing what, where, and against which exit criteria.

• Unit tests — Apex tests with meaningful assertions, covering the happy path, negative cases, bulk behaviour and different user permissions with System.runAs. Callouts mocked, data created in the test rather than queried.
• Static analysis and code review — run automatically on every pull request, so the mechanical problems never reach a human reviewer.
• Functional and integration testing — in the shared integration environment, covering declarative automation and the interfaces, which Apex tests do not reach.
• Automated regression — critical business journeys, run on every build and before every release. This is the investment that makes a frequent cadence possible.
• UAT — business users in a production-like environment, with agreed entry criteria, a defined scenario set, a severity model and acceptance criteria settled before the cycle starts.
• Performance and data-volume testing — where the requirement warrants it, in the most production-like environment available.
• Platform release regression — three times a year, in a sandbox on a preview instance during the preview window.

Underneath all of it sits a single test data strategy, including masking wherever data leaves production, because otherwise every environment ends up with a different definition of realistic.