Skip to content
SDLC Studio

TSD - Test Strategy Document

The Test Strategy Document is the project-level answer to how do we know it works? It defines what to test, how, when, and who is responsible - one strategy per project, which the individual test specs then apply to specific stories. It is owned by Sam, the QA seat of the Three Amigos.

It lives at sdlc-studio/tsd.md.

What a Test Strategy Document defines

Section titled “What a Test Strategy Document defines”
  • What to test - scope, levels and types (unit, integration, E2E, performance, security).
  • How to test - frameworks and the automation approach.
  • When to test - CI/CD integration and the quality gates that block a build.
  • Who tests - roles and responsibilities.

Its sections: Overview & Objectives · Test Scope (in / out) · Test Levels · Test Environments · Test Data Strategy · Automation Strategy · CI/CD Integration & Quality Gates · Defect Management · Roles & Responsibilities · Tools & Infrastructure.

Three modes

Section titled “Three modes”
  • tsd (create) - a guided conversation about objectives, test levels, framework preferences, the automation approach and the quality gates. A PRD should exist first, for context.
  • tsd generate - reads your test files and CI config, identifies the frameworks in use (Jest, Playwright, pytest, …), documents current coverage and gaps, and writes the strategy with [INFERRED] markers.
  • tsd review - re-checks the strategy against the codebase and updates tool versions, gates and levels.

Quality gates

Section titled “Quality gates”

The TSD is where you decide what blocks a build. A typical set:

Gate Criteria Blocking
Unit coverage ≥ 90% Yes
Integration tests 100% pass Yes
E2E critical path 100% pass Yes
Performance p95 < 500ms Yes

How the rest of the pipeline uses it

Section titled “How the rest of the pipeline uses it”

This is worth stating precisely, because it is easy to assume the TSD is checked line by line - it is not:

  • The status dashboard measures real coverage against the targets the TSD sets - that is how a project knows it is below its own bar.
  • At sprint close, the TSD is one leg of the unified review (PRD / TRD / TSD / personas, plus the code), so the strategy is re-examined against what actually shipped.

Where to next

Section titled “Where to next”