A contract with an external QA team: fix the result, not the hours

A weak testing contract describes hours and rates. A strong one describes the result: which deliverables, by which criteria and by which date the team hands over to the client, what happens with a blocker on release day and how volume is counted. The difference shows in the first dispute about whether something was "tested".

Subject of the contract

The subject is worded through types of work and boundaries: functional, regression, load testing, LQA — of what exactly, on which environments, what is excluded. For clients from Russia the wording of the subject also has tax significance: testing, localization and support go into one contract, while development — including regression automation — goes into a separate one, because they are taxed differently. This part is worth agreeing with an accountant before signing.

• Types of testing tied to the product and environments.
• What is excluded: development, automated tests, defect fixing, security — unless agreed separately.
• Languages for LQA and channels for support, if they are in scope.
• Interaction format: tracker, chat, calls, reporting.

Deliverables as the measure of the result

The result of testing is measured in documents, not hours. The contract lists deliverables per stage and their minimum content: a test plan with exit criteria, a regression suite in the client's tracker, a run report, a defect register with severity and priority, a release readiness report with a recommendation, load protocols, an LQA report with screenshots. The act is closed by hand-over of deliverables, not by the end of the month.

Timings and SLA

1. Response time to a client request and to a new build — in business hours.
2. Blocker escalation time: the day it is found, in the team chat, with reproduction.
3. Pre-release regression time with an existing suite — usually within a working day per environment.
4. Readiness report deadline — a day before the planned release.
5. What happens when the client moves the release or delivers the build late — who bears the cost of a repeat run.

Acceptance and disputes

Acceptance goes by the exit criteria from the test plan and the list of deliverables: regression passed, no blockers, deliverables handed over — the stage is accepted. The dispute "it was tested but broke in production" is settled by the report: if the defect was in an unchecked zone named in the report — that is the client's conscious risk; if in a checked one — grounds for a claim against the contractor. That is why a readiness report with an explicit list of the unchecked protects both sides.

Access, data and confidentiality

• A list of access: test stands, tracker, payment gateways in test mode, analytics — through separate accounts with minimal rights.
• Test data: who prepares accounts and promo codes, whether real user data is allowed (almost always — no).
• Confidentiality: what counts as a secret, the term, the procedure for returning and revoking access after completion.
• Storage of deliverables: in the client's systems, so they remain with the client after the contract ends.

Volume-based pricing

For one-off work — a fixed estimate from the test plan. For release support — a volume in tester days per month recalculated on actuals for the first month, then a fixed rate with a range. For LQA — per language and device, for support — per request volume and coverage hours. Scope changes are agreed in writing before work starts, not after.