Test Strategy: A Practical Guide

Test strategy vs test plan vs test approach

The three terms are used loosely in practice, so it helps to fix them. A test strategy is a long-lived description of how testing is performed across an organisation, a programme or a product line. A test plan is a project- or release-level document that says what will be tested this time, how, by whom, when, with which resources and under which criteria. A test approach is the way the strategy is implemented for a specific project: the chosen mix of techniques, levels, types and entry/exit criteria recorded in the plan.

ISO/IEC/IEEE 29119-3, the test documentation part of the 29119 series, separates organisational-level documentation from project-level documentation. At organisational level sit the test policy (why the organisation tests and what it expects from testing) and the organisation’s standing test practices, which the 2013 edition called the organisational test strategy. At project level the central document is the test plan, and the plan itself records the test strategy chosen for that project. The ISTQB Foundation syllabus uses the term test approach for the same project-level choices. Whatever names your organisation uses, keep the two levels apart: one set of rules that rarely changes, and one plan per release that applies them.

• Strategy — organisation or product level; answers "how do we test here?"; reviewed every few months or after a major incident.
• Plan — project, release or sprint level; answers "what are we testing now, and when is it done?"; updated whenever scope, dates or risks change.
• Approach — the concrete application of the strategy inside a plan: the techniques, levels, types and criteria for this scope.
• Policy — above both: a short statement of why testing exists in the organisation and what it must achieve.

What a test strategy contains

A strategy is useful when a new team member can read it and make the same decisions an experienced one would. That requires specific content, not a general statement that "quality is everyone’s responsibility". The following headings cover what most organisations need; small teams can fit them on two or three pages.

• Scope — the products, platforms, components and interfaces the strategy covers, and what it explicitly does not cover (for example third-party systems tested only at the integration boundary).
• Test objectives — what testing must achieve: find defects in high-risk areas early, give evidence for the release decision, protect regulated flows, keep regression cost under control.
• Quality characteristics — which ISO/IEC 25010 characteristics matter for this product and how deeply each is tested: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility and safety.
• Test levels and types — unit, integration/API, system and acceptance; functional, regression, exploratory, performance, security, accessibility, localisation; and who owns each.
• Risk approach — how product risks are identified, scored and used to set test depth and order (covered in depth in the risk-based testing guide).
• Test design approach — the techniques expected per kind of requirement: equivalence partitioning and boundaries for inputs, decision tables for business rules, state transitions for workflows, exploratory sessions for new features.
• Environments and test data — which environments exist, how close they are to production, how external services are sandboxed or mocked, and how test data is created (synthetic, never copied personal data).
• Automation strategy — what is automated at which level, where it runs in CI/CD, who maintains it and when a test is retired.
• Tools — test management, defect tracking, automation frameworks, CI, reporting; named by category and, where settled, by product.
• Entry and exit criteria — the default conditions for starting and finishing each level, which plans may tighten but not silently weaken.
• Metrics and reporting — the few measures used for decisions, how often they are reported and to whom.
• Roles and responsibilities — QA lead, testers, developers, product owner, DevOps, security; who approves the release.
• Defect management — the severity and priority scales and the path from report to closure.

Types of test approaches

Testing literature commonly groups test approaches into a handful of categories. Earlier ISTQB Foundation syllabi (for example the 2018 edition) listed them explicitly; the current CTFL v4.0 syllabus discusses the test approach as part of test planning rather than as a named list. The categories are still a useful vocabulary, because almost every real strategy is a deliberate mix of them.

• Analytical (risk-based) — testing is derived from an analysis of some factor, most often product risk: the areas most likely to fail with the highest impact get the most and earliest testing.
• Requirements-based — often treated as a form of analytical approach: tests are derived from requirements or acceptance criteria and traced back to them, so coverage can be shown per requirement.
• Model-based — tests are generated from a model of the system’s behaviour, such as a state machine, a business process model or a usage profile.
• Methodical — a predefined set of test conditions is applied systematically: a checklist of common failures, a quality characteristic taxonomy, or the organisation’s standard checks for every form or API.
• Process-compliant (standard-compliant) — testing follows an external rule set: an industry standard, a regulator’s requirements, or a mandated documentation process.
• Directed (consultative) — the choice of what to test is driven by advice from stakeholders or domain experts outside the test team, such as a payments specialist or the business owner.
• Regression-averse — the priority is to avoid breaking existing behaviour: reuse of test assets, extensive automated regression suites and standard test suites.
• Reactive — testing reacts to the product as it is found rather than being fully planned in advance; exploratory testing is the main example.

How to choose and combine approaches

No single approach is enough. A payment flow in a regulated fintech product needs risk-based depth, requirements traceability for the auditor, process compliance for the regulator’s rules, regression-averse automation because it changes often, and exploratory sessions because users will do things nobody specified. A marketing landing page needs a methodical checklist and not much more. The strategy should state, per product area, which combination applies and why.

Choose by looking at the context rather than at preferences. The context-driven school of testing makes this point strongly: a practice is good or bad only relative to the product, the people and the constraints in front of you.

• Risk profile — money, personal data, safety or legal exposure push towards analytical and process-compliant approaches with more documentation.
• Regulation and audit — if someone outside the team must see evidence, requirements-based traceability and a documented process are not optional.
• Change rate — frequent releases of a stable core favour regression-averse automation; a new product with unclear requirements favours reactive and consultative testing.
• Quality of the test basis — precise, reviewed requirements support requirements-based and model-based design; vague ones mean more exploratory work and requirement reviews first.
• Team skills and tools — model-based testing without people who can build and maintain models is a plan on paper only.
• Lifecycle — in iterative delivery the strategy is applied sprint by sprint by the whole team; in sequential projects it is applied per phase with formal entry and exit points.

Try it: Risk-Based Test Generator Try it: AI Risk-Based Test Generator

From strategy to execution: planning, risk, estimation and metrics

A strategy becomes work through four activities, each of which has its own guide in this topic. The test plan applies the strategy to a release: scope, items, features in and out, approach, criteria, environments, schedule, people, risks and deliverables. Risk-based testing is the analytical core of most strategies: identifying product risks, scoring them by likelihood and impact, and turning the scores into test depth and order. Test estimation turns the planned scope into effort and time with ranges and stated assumptions instead of a single optimistic number. Test metrics close the loop: coverage, defect trends, escaped defects and suite health tell you whether the strategy is working and where to change it.

Traceability links all four. When each requirement or acceptance criterion maps to tests, and each test result maps back, the plan can show what is covered, the risk analysis can show which high-risk items are still untested, and the metrics mean something. Keep the requirement-to-test matrix alive from the first sprint rather than reconstructing it before an audit.

Try it: Requirements → Test Cases Try it: AI Test Coverage Analyzer

Example: a strategy outline for a Saudi e-commerce product

For example, consider Bustan Market, a fictional marketplace selling to customers in Saudi Arabia through a bilingual Arabic/English website and iOS and Android apps, with card, mada, Apple Pay and cash-on-delivery payments. The outline below is the kind of strategy a QA lead could write for it in two pages. Every number in it is an example chosen for the fictional product, not a recommendation for yours.

TEST STRATEGY - Bustan Market (fictional example)          v1.2 - owner: QA lead

Scope
  In:  web storefront (ar/en), iOS and Android apps, seller portal, public API v2,
       checkout and payments (card, mada, Apple Pay, cash on delivery), order tracking
  Out: courier partner systems (tested at our integration boundary only),
       ERP internals (owned by finance IT)

Objectives
  - No known Blocker/Critical defect in checkout, payment or refund at release
  - Every acceptance criterion traced to at least one executed test
  - Core journeys covered by automated regression that runs on every merge

Quality characteristics (ISO/IEC 25010) and depth
  Functional suitability   high    requirements-based + risk-based design
  Security                 high    OWASP ASVS baseline; external pen test before major releases
  Performance efficiency   high    p95 checkout API < 800 ms at 3x normal peak (sale days)
  Interaction capability   medium  Arabic RTL, accessibility checks on core journeys
  Compatibility            medium  top browsers/devices from analytics, reviewed quarterly
  Reliability              medium  payment gateway timeouts, retries, idempotent orders

Test levels and owners
  Unit (developers, CI) - API/integration (developers + QA, CI) - system/E2E (QA)
  - acceptance (product owner + QA) - post-deploy checks (DevOps + QA)

Risk approach
  Product risk register per release; likelihood x impact on 1-5 scales;
  score >= 15: boundary, negative, exploratory and automated regression coverage

Test design
  Partitions and boundaries for amounts, quantities, coupons; decision tables for
  promotion rules; state transitions for order status; exploratory session per feature

Environments and data
  Staging mirrors production versions; payment provider sandbox; synthetic data only
  (Arabic/English names, +9665 mobile numbers, SA IBAN format); no production copies

Automation
  API regression on every merge; 25-30 E2E journeys nightly and pre-release;
  mobile smoke on real devices before store submission

Entry / exit (defaults)
  Entry: build deployed, smoke green, acceptance criteria reviewed
  Exit:  planned tests executed; 0 open Blocker/Critical; Major defects have an agreed
         plan; regression green; performance target met

Metrics and reporting
  Daily status in the squad channel; release report with requirement coverage, open
  defects by severity, escaped defects from the previous release, suite duration, flaky rate

Roles
  QA lead (owns strategy), squad testers, developers (unit/API tests), product owner
  (acceptance, impact scores), DevOps (environments), security lead (pen test scope)

Review: quarterly, and after any Critical production incident

Try it: AI QA Checklist Generator Try it: Regression Scenario Generator

How to write and maintain a test strategy

• 1. Collect the inputs: the test policy if one exists, the product architecture, regulatory and contractual obligations, the last year of production incidents and escaped defects, and the team’s skills.
• 2. Decide which quality characteristics matter and how deeply; write this as a short table so trade-offs are visible.
• 3. Choose the mix of approaches per product area and state the reason in one sentence each.
• 4. Define levels, types and ownership so that no activity belongs to "everyone" and therefore to nobody.
• 5. Set the default entry and exit criteria, the defect scales and the handful of metrics that will be reported.
• 6. Review the draft with development, product, DevOps and security leads; a strategy the developers have not read will not be followed.
• 7. Publish it where plans link to it, and review it on a fixed cadence and after serious incidents — an escaped Critical defect is evidence that some decision in the strategy was wrong.

Common mistakes

• Writing a strategy that is really a plan — dates, names and sprint scope in a document that should outlive the release.
• Copying a generic template: every section filled, no decision made. If a sentence would be true of any product, it is probably not needed.
• Treating all features equally instead of setting depth by risk.
• Listing only functional testing; performance, security, accessibility and localisation then happen by accident or not at all.
• An automation strategy that says "automate everything" without saying at which level, who maintains it and how flaky tests are handled.
• Exit criteria nobody enforces — they become decoration, and the release decision goes back to opinion.
• Never revisiting the strategy after incidents, team changes or a move from sequential releases to continuous delivery.

Frequently asked questions

References

• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021Templates and content for test documentation — test policy, strategy, plan, status and completion reports, incident reports.
• ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesISO/IEC/IEEE · 2021The test process model: organisational, test management and dynamic test processes, with their activities and outcomes.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024ISTQB's advanced syllabus on managing testing: test planning and estimation, risk-based testing, monitoring, metrics and reporting.
• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023The product quality model: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability and flexibility.
• ISO/IEC/IEEE 29119-1:2022 — Software and systems engineering — Software testing — Part 1: General conceptsISO/IEC/IEEE · 2022The international software-testing standard: concepts, processes, documentation and techniques.
• Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)Addison-Wesley (Pearson) · 2009The agile testing quadrants and how testers work inside a delivery team — the basis of "testing at the right layer".
• Lessons Learned in Software Testing: A Context-Driven Approach (Cem Kaner, James Bach, Bret Pettichord)Wiley · 2001Practical lessons on bug reporting, test design, automation and managing testing — the context-driven school.