What a test strategy document should contain

Why the strategy matters in selection

A test strategy is where a vendor shows that it understands your product. Rates, headcount and certifications look similar across proposals; the strategy does not. It is also the document you will use later to hold the vendor to what it said it would do.

ISO/IEC/IEEE 29119-3 is the international standard for software test documentation. It defines the documents a test process produces, from organisation-level test practices down to test plans, status reports and completion reports. You do not need to buy the standard to use it as a checklist, and you should not require vendors to follow its templates word for word. Use it to check that nothing important is missing.

The sections to look for

The table below lists what a strategy for your product should cover. The RFP builder asks vendors to answer against these same headings, so the answers line up.

Section	What it should say	What a weak version looks like
Context and scope	Your product, the parts in scope, the test basis (requirements, designs, user stories)	A description of the vendor's methodology
Out of scope	What will not be tested, and why	Missing, or "all functionality will be tested"
Risks	Product and project risks in priority order, with how testing addresses each	Generic risks such as "tight deadlines"
Test levels and types	Unit, integration, system, acceptance; functional and non-functional	A list of every test type the vendor offers
Techniques	How tests are designed: boundary values, state models, exploratory charters	"Industry standard techniques"
Automation approach	What will be automated, in which framework, where the code lives, how it runs in your pipeline	A promised automation percentage with no base
Environments	Which environments are needed, who provides them, how close they are to production	Not mentioned
Test data	How data is created, masked or synthesised, and who approves any real data	"Client to provide test data"
Entry and exit criteria	Measurable conditions to start and finish a cycle	"Testing complete when all tests executed"
Defect management	Severity definitions, workflow, who triages	A tool name only
Reporting	What is reported, how often, to whom	"Regular status updates"
Roles	Who does what on both sides, including who decides a release is ready	Vendor roles only
Schedule and estimates	Activities against your release calendar	A single overall duration

Non-functional quality

A strategy that covers only functional testing leaves out much of what can hurt you. ISO/IEC 25010 describes product quality characteristics beyond functional suitability, including performance efficiency, compatibility, usability, reliability, security and maintainability. You do not need all of them; you do need the strategy to say which ones apply to your product and which the vendor will not cover.

For accessibility, the strategy should name the standard and level, such as WCAG 2.2 AA. For security, it should say what is tested and what is left to a specialist penetration test.

Signs of a copy-paste document

Vendors reuse material, and that is fine for sections such as defect workflow. It is not fine for scope and risk. Look for:

• another client's product name, domain terms or technology left in the text;
• risks that would apply to any software ("requirements may change");
• no mention of your release frequency, team structure or existing tests;
• a list of test types with no statement of which apply to you;
• exit criteria that can always be met, such as "all planned tests executed";
• no "out of scope" section at all.

A useful test: ask the vendor's lead to explain, in a call, why the three highest risks are in that order. Someone who wrote the strategy can answer. Someone who assembled it cannot.

Exit criteria and who says no

The most important sentence in a test strategy is the one that says who can stop a release. The UK government service manual expects teams to test their service regularly and to treat quality as part of delivery, not a gate at the end. In practice, testing produces evidence and your team makes the decision. Wording to look for:

Exit criteria for a release: no open defects of severity 1 or 2; all regression tests for changed areas executed with results recorded; any failed or skipped tests listed with a risk note. The Customer's release owner decides whether to release on the basis of this evidence.

Be wary of a strategy where the vendor certifies release readiness itself and gives you only a pass or fail.

How to use the strategy after signature

Make the strategy a deliverable with acceptance criteria. Ask for it within the onboarding period, review it with your engineers, and update it when your product or process changes. Compare each test summary report against it: did the vendor test what the strategy said, and report on the exit criteria it set?

Use the questionnaire to ask for an anonymised example during selection, and see the RFP guide for how to describe your product so that a vendor can write something specific.