Test strategy vs test plan for a fintech product: definitions and the template we use

Two definitions that disagree, checked on 22 September 2026

The glossary of the International Software Testing Qualifications Board (ISTQB) defines a test strategy as "A description of how to perform testing to reach test objectives under given circumstances." Version 4 of the entry (23 April 2023) gave the term "a generic meaning, applicable to various scopes". The glossary defines a test plan as "Documentation that describes test objectives, means and schedule for achieving test coordination." That wording is version 3, added on 11 March 2026, with ISO/IEC/IEEE 29119-1 (2013) as its reference.

ISO/IEC/IEEE 29119-3:2021 (published 28 October 2021) draws the line elsewhere. Clause 3.19 defines a test plan as a "detailed description of test objectives to be achieved and the means and schedule for achieving them, organized to coordinate testing activities for some test item or set of test items". Clause 3.25 makes the test strategy a "part of the test plan (3.19) that describes the approach to testing for a specific project, test level or test type". The organisation-wide document is clause 3.5, organizational test practices. We read clause 3 in the public preview on 22 September 2026.

The introduction of ISO/IEC/IEEE 29119-1:2022 (published 4 February 2022) places both documents "in the context of risk-based testing, which is the recommended approach to strategizing and managing testing that underlies the ISO/IEC/IEEE 29119 series". In our documents, "strategy" follows the ISTQB meaning at organisation scope, which matches what 29119-3 calls organizational test practices, and "plan" means one release. When an auditor asks for "your test strategy", ask which scope they mean.

What breaks when each release plan carries its own strategy

Note 1 to clause 3.25 puts "test data; test environment and testing tool requirements; and expectations for test deliverables" inside the plan. Re-deciding them per release produces failures we find in QA audits:

• Risk tier chosen under deadline. A late fee change filed as a copy update skips the reconciliation replay, and the fee posts to customers who paid on the due date. Each fee is refunded and each complaint handled.
• Test data chosen per release. A team copies a production extract to reproduce a defect, and customer account data lands in staging, outside the access controls of production.
• Evidence format chosen per release. An auditor sampling the audit period finds build identifiers on some records and undated screenshots on others. The fields a record needs are on the audit and certification test evidence page; the strategy fixes that format once.

Our template: strategy rows and release plan rows

The split below is our practice; neither the ISTQB glossary nor ISO/IEC/IEEE 29119 prescribes it. Keep the row order when you copy the table.

Filled example: a partial refund release in a BNPL product

The example product is synthetic: a buy now, pay later (BNPL) service with pay-in-4 orders. Release R-26.19 recalculates the remaining instalments after a partial refund. The example's product rule applies a refund to the unpaid balance first, credits any excess to the card, and gives the extra cent of an uneven split to the earlier instalment.

Each new case must satisfy one invariant: amount paid, minus card credit, plus new instalments, equals the order amount minus the refund.

case,order,paid_count,paid_amount,refund,new_inst_2,new_inst_3,new_inst_4,card_credit
REF-015,100.00,2,50.00,30.01,paid,10.00,9.99,0.00
REF-016,100.00,2,50.00,50.00,paid,0.00,0.00,0.00
REF-017,100.00,2,50.00,70.00,paid,0.00,0.00,20.00
REF-018,100.00,1,25.00,0.01,25.00,25.00,24.99,0.00
REF-019,99.99,2,50.00,10.00,paid,20.00,19.99,0.00

The check below reads that data saved as ref.csv and tests the invariant and the split rule. We ran it with Python 3.13.1; all five rows print ok.

import csv
from decimal import Decimal

CENT = Decimal("0.01")

with open("ref.csv", newline="") as f:
    for row in csv.DictReader(f):
        new = [Decimal(row[k]) for k in ("new_inst_2", "new_inst_3", "new_inst_4") if row[k] != "paid"]
        left = Decimal(row["paid_amount"]) - Decimal(row["card_credit"]) + sum(new)
        right = Decimal(row["order"]) - Decimal(row["refund"])
        split_ok = all(a >= b and a - b <= CENT for a, b in zip(new, new[1:]))
        status = "ok" if left == right and split_ok else f"BREAK sum {left} vs {right}, split {new}"
        print(row["case"], status)

Binary floats cannot hold most cent values exactly, so amounts are parsed as Decimal; the banker's rounding guide covers ties at half a minor unit.

How we keep the two documents apart

• A release plan cites strategy rows by name and never restates them. A deviation is a waiver row with an approver and an expiry date.
• The strategy changes only on a review trigger and gets a new version number. Each release plan records that version, so an auditor sampling releases sees which rules applied.
• A release that touches a flow missing from the strategy stops at the entry gate until the strategy adds the flow and its tier.

When the strategy is missing or out of date, our QA audit and test strategy engagement produces it in this shape. BNPL failure patterns are on the BNPL segment page.