Software testing statement of work: what goes in it

From proposal to commitment

A proposal describes what a vendor would like to do. A statement of work (SOW) describes what it must do. Everything that made you choose the vendor, such as named people, a test strategy, a reporting format, ownership of code, needs to move from the proposal into the SOW, or it is not a commitment.

FAR Subpart 37.6, on performance-based acquisition, asks that work statements describe required results in measurable terms rather than only how the work is done. That is a useful test for each SOW line: can you tell whether it was delivered?

Sections of a testing SOW

Section	What it contains
Purpose and background	One paragraph on the product and the goal of the engagement
Scope in	Products, platforms, test levels and types, environments, activities
Scope out	Everything a reader might assume is included but is not
Deliverables	Each item with content, format, due point, owner, acceptance criteria
Team and key people	Roles, named key people, allocation, replacement terms
Service levels	Targets, measurement method, reporting, remedies
Environments, tools and data	What you provide, what the vendor provides, accounts, data rules
Assumptions and dependencies	Numbered list, with the effect if one fails
Change control	How changes are raised, estimated, approved and priced
Price and payment	Model, rates, milestones, invoicing evidence
Ownership and exit	Where assets live, who owns them, handover at end
Governance	Meetings, reports, escalation path

Scope: in and out

Write scope as lists. For example:

In scope: functional and regression testing of the web app and iOS and Android apps; API testing of the public API; test automation for regression using the open-source framework agreed in the test strategy; test reporting per release.

Out of scope: penetration testing; load testing beyond smoke checks; testing of third-party payment pages; production monitoring.

A clear out-of-scope list prevents disputes more than anything else in the SOW.

Deliverables and acceptance

ISO/IEC/IEEE 29119-3 describes test documentation such as the test strategy, test plan, test completion report and defect reports. Use it as a checklist for which documents to require. For each deliverable, write how you accept it:

• "Test plan for release 1, covering the sections in Annex A, delivered within [N] working days of start. Accepted when reviewed and approved in writing by the Head of Engineering."
• "Automated regression suite for the checkout journey, in the buyer's repository, running in the buyer's CI pipeline, with a pass rate on a stable build agreed in the test plan. Accepted after a run observed by the buyer."

The contract clauses tool includes an acceptance clause you can attach.

Service levels

Each service level needs a target, a measurement method, a reporting frequency and a remedy. "Timely reporting" is not a service level. "Test completion report within [N] working days of the end of each release test cycle, measured from the cycle end date in the test management tool" is one. See SLA metrics that matter for which ones to choose.

Assumptions and dependencies

Proposals are full of assumptions: environments available by a date, test data provided, a stable build each sprint. Move every one into a numbered list. For each, state what happens if it fails: a change request, a revised timeline or no effect. Assumptions you do not accept should be removed before signing, not after the first change request.

Change control

State who can raise a change, how it is estimated, who approves it on your side, and the rates used. Work done before approval is at the vendor's risk. This keeps a narrow scope from turning into a stream of priced extras.

Ownership and exit

Write that test code, test cases, data and documentation are created in repositories and tools under your accounts from day one, and that IP is assigned to you under the master agreement. Add the handover list for exit. Test automation code ownership and exit planning cover the detail.

Check against the master agreement

The UK Model Services Contract, for example, keeps its core terms separate from the schedules that describe the services. Read the SOW next to your master agreement and remove anything in the SOW that weakens the master terms, such as a different liability cap or a vendor licence to reuse your test assets.

Use the RFP generator output as the starting point for scope and deliverables, since vendors already responded to it.

The selection path shows where the SOW sits: after evaluation and verification, alongside contract negotiation.