Test Scope

Why it matters

Unclear scope fails in two directions. Gaps appear when everyone assumes someone else tests an area — refunds, the Arabic receipt, the older app version customers still use — and its first test happens in production. Waste appears when the team spends days on areas that did not change or that another team owns.

Scope is also the input to the estimate, the schedule, the environments and the exit criteria. When scope grows and nobody adjusts them, the team either misses the date or releases with tests silently skipped. For the tester, a written, agreed scope is protection as well as a duty: a defect in an area excluded for a reason the product owner accepted leads to a discussion about that decision, not about blame — and you are expected to say what each exclusion risks.

What a test scope defines

A useful scope statement is specific enough that two people give the same answer to "is this tested?": it names items by ID and version, not by words such as "checkout" or "the app". Start from the default scope in the test strategy and apply it to what changed, across these dimensions:

• Test items: the parts of the test object to be tested, such as applications and services, each with its version, for example web 4.2, the iOS and Android apps 4.2 and payments API v3.
• Features and changes: stories, requirements or change requests by ID, plus the existing features the change affects.
• Quality characteristics and test types: functional, performance, security, accessibility, compatibility — and which apply this time.
• Test levels: for example system and system integration testing by QA, component testing by developers in CI.
• Platforms, browsers, devices, languages and regions that will actually be used.
• Interfaces: where our testing stops, such as "our side of the payment provider integration, in its sandbox".
• Depth: in scope is not a yes/no flag. In the ISTQB syllabus, product risk analysis determines both the test scope and its thoroughness: each item gets a risk level and the depth that follows from it.

Try it: Risk-Based Test Generator

Out of scope: a decision with a reason

An out-of-scope list is a list of decisions, not of things you forgot. Each exclusion records the item, the reason, who covers it instead and who agreed; if it leaves a risk, the person who owns the release, usually the product owner, accepts that risk explicitly. ISO/IEC/IEEE 29119-3, the test documentation standard, asks for the core of this in a test plan’s test scope: the features excluded from testing and the rationale for excluding them.

An exclusion is agreed explicitly: when the scope is agreed before testing starts, or later as a recorded scope change. A planned test that was not executed — blocked environment, no time left — is not "out of scope": it is a coverage gap that the progress and completion reports must show as residual risk.

Reasons that usually hold up in a scope review:

• Unchanged and not affected by the change; the regression suite covers it.
• Owned by another team or a vendor: they test it; you test your side of the interface and ask for their evidence.
• Not part of this release.
• Not testable in the available environments: state what replaces it, such as mocked responses or a check after deployment.
• Low risk, explicitly accepted by the product owner.

How to agree and document scope

Testing proposes the scope; the people who own the product and the release agree it, usually in a short scope review.

• Collect the basis: release notes, stories and acceptance criteria, the change list and the strategy’s default scope.
• Find what the change touches: ask developers which components, data and integrations are affected; traceability shows the linked requirements and tests.
• Draft both lists — in scope with ID, risk and depth, out of scope with reason and owner — and mark open questions instead of guessing.
• Review them with the product owner, the development lead and anyone covering an excluded item. Read the out-of-scope list aloud; misunderstandings surface there.
• Record the result in the test plan’s scope section or the one-page sprint test plan, with version, date and approver.
• Agree the change rule: who may request a change, who estimates its impact and who decides.

Try it: Requirements → Test Cases

Worked example: the scope of an instalment-payments release

The statement below is the agreed scope for Bustan Market 4.2 after a 30-minute review. Every out-of-scope line has a reason and an owner, the boundary with the provider is precise, and the one accepted risk is written down.

The depth column turns each risk level into concrete tests: BUS-902 lists the 2-value boundary values of the eligibility range, and the regression line brings the unchanged payment methods into scope because they share the changed checkout code.

TEST SCOPE - Bustan Market 4.2 "Pay in instalments" (fictional)          v1.0
Basis: BUS-901..905, test strategy v1.2     Agreed: PO, dev lead, QA lead (day 1)

IN SCOPE                                            Risk    Depth
BUS-901  Instalment option at checkout,             High    boundaries, negative,
         web + iOS + Android, ar/en                         exploratory, auto API
BUS-902  Eligibility: total 200.00 to 5,000.00      High    199.99 / 200.00 /
         SAR, signed-in customers only                      5,000.00 / 5,000.01
BUS-903  Instalment schedule in "My orders"         Medium  dates, amounts, ar/en
BUS-904  Refund, partial refund, cancellation       High    before and after the
         of instalment orders                               first instalment
BUS-905  Our handling of provider webhooks          Medium  approved, declined,
         (approved, declined, expired)                      expired, duplicate
Regr.    Card, mada, Apple Pay, cash on delivery    Medium  automated checkout
         (they share the checkout code)                     suite + 2 devices

OUT OF SCOPE                Reason                      Covered by
Provider credit decision    provider-owned service      provider; we test our
and the provider app                                    side in its sandbox
Seller portal               unchanged in 4.2            nightly regression suite
Load test of provider API   not ours to load-test       provider SLA (PO agreed)

Accepted risk  provider outage tested with mocked responses only (PO, day 1)
Assumptions    provider sandbox from day 1; synthetic customers only
Changes        request to PO -> QA impact note -> PO decides -> scope v1.1, v1.2

Scope creep: recognise it and control it

Scope creep is the growth of scope after it was agreed, without a matching change to time, people or exit criteria. It rarely arrives as a formal request: it looks like "while you are at it, can you also check…", acceptance criteria rewritten after test design (compare the old and new text to see exactly what changed), or a late change merged into the release branch.

Change itself is normal. The 2020 Scrum Guide says that during a Sprint, scope may be clarified and renegotiated with the Product Owner as more is learned, and that no changes are made that would endanger the Sprint Goal. The problem is change that bypasses the agreement.

In week 2 of the Bustan Market release a message arrives: "Can instalments also work for gift card orders? Small change." The tester replies with an impact note (a separate refund rule, gift card checkout regression, about three extra tester-days) and three options: extend testing, move it to 4.3, or reduce exploratory testing of the instalment option (BUS-901) with that risk accepted. The product owner chooses 4.3; scope v1.1 records it.

• Assess: new tests, regression, effort and risk.
• Offer options: more time, defer the change, or reduce something else with its risk accepted.
• Decide and record: the owner chooses; update the scope version, the estimate and the exit criteria.
• Watch the reverse: dropping planned tests at the end for lack of time also changes the agreed scope; it needs the same decision and is reported as residual risk, not relabelled as out of scope.

Try it: Regression Scenario Generator Try it: Text Diff

Frequently asked questions

References

• 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.
• 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.
• The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020The definition of Scrum: its accountabilities, events and artifacts, including the Definition of Done that testing helps meet.