How to Define Test Scope With Explicit Inclusions and Exclusions

“Test the address change” leaves several decisions hidden. Does it include mobile web? Does it include an unchanged order-history page that shares a dependency? Does excluding receipt download mean the feature is unsupported, or only that this release will not test it? A useful test scope definition makes those boundaries visible before people estimate or execute the work.

The practical deliverable is a versioned statement of what testing is intended to cover, what it explicitly excludes, why those decisions follow from the available basis, and which questions still prevent acceptance. A feature-and-platform table makes that statement reviewable without turning it into a full test plan.

Define the Boundary Before Planning Execution

Start with the question, “What belongs inside this release's testing boundary?” Identify the features, affected interfaces, platforms and relevant quality obligations. Explain exclusions with the same precision as inclusions. A broad label such as “checkout” is insufficient if desktop and mobile use different paths or the change affects a shared service.

Tricentis's educational scope guide distinguishes what is and is not tested from a broader test plan and strategy. Testsigma's guide also recommends explicit inclusions and exclusions, stakeholder review and ongoing updates, although it uses a broader scope-document definition. The method below keeps the boundary separate so it can inform those larger planning artifacts.

Scope should identify applicable functional, security, accessibility or other required testing dimensions. It need not contain the staffing plan, calendar, detailed approach, individual test cases or their execution order. Those decisions depend on the boundary and may reveal feasibility problems, but a case-ranking score cannot resolve an unclear requirement or authorize an exclusion.

Keep planned scope separate from evidence. An included feature has not necessarily been tested; an accepted boundary is not a pass report. Conversely, an environment failure does not retrospectively turn required work into an approved exclusion.

Anchor Scope to a Versioned Test Basis

Record the release identifier, testing objective and exact versions of the requirements, acceptance criteria, change register, support statement and applicable agreements or policies. These references form the test basis: the material used to explain why a boundary is proposed. A source title without a revision can conceal a disagreement between reviewers working from different inputs.

Then inspect change context. A changed feature belongs in the discussion, but unchanged features can also be affected through shared services, data or interfaces. Ask engineering to substantiate the impact boundary. “No code changed here” does not establish that the feature is unaffected.

Check contractual and regulatory obligations before negotiating exclusions. Where applicability or required coverage is unknown, record the question and the appropriate review role. Do not label an area optional merely because nobody has supplied the agreement, the environment is unavailable or the schedule is short. A requested exception is not an approved waiver, and a scope document does not itself waive an obligation.

Work Through a Fictional Scope Packet

The following source packet is deliberately small enough to review clause by clause. It is an unexecuted teaching example, not a customer project or a report of actual testing. Its proposed roles, requirements and decisions exist only within the illustration.

Release and Change Basis

SCP-19 v1 is a fictional, unexecuted scope proposal for the Parcel Desk release R7. It covers three features: F1 delivery-address editing, F2 receipt download and F3 order history. Objective O1 is to define the release's changed-feature and affected-regression boundaries, including the applicable access-control obligations. No test cases, application runs, tenant changes or stakeholder decisions have occurred.

The versioned test basis is Change Register CR-7 v3, Support Statement SUP-7 v1, Access Policy SEC-7 v2 and Release Agreement RA-7 v1. CR-7 v3 sections A and B change F1 address validation on desktop and mobile web and F2 receipt generation on desktop web. Section C says F1 uses a shared profile lookup, but whether F3 order history depends on that lookup is unknown. F3 impact must be clarified on both platforms before the proposed boundary can be accepted.

SUP-7 v1 declares all three features supported on P-D desktop web with Chrome on Windows and P-M mobile web with Safari on iOS. Exact browser and operating-system versions are required but unspecified. This scope proposal must not invent them. CR-7 v3 section B explicitly excludes F2 mobile-web receipt download from this release's test scope because its receipt path is unchanged and the supplied impact statement says it does not use the changed generator. This exclusion is a testing decision, not a claim that mobile receipt download is unsupported.

Obligations, Unknowns and Authority

SEC-7 v2 requires owner-only access checks for every included feature on every included platform. RA-7 v1 requires assessment of any applicable contractual or regulatory testing obligations before scope acceptance; the obligations review has not yet been supplied. Neither lack of time nor an unavailable environment permits required feature, platform or security coverage to be silently excluded. A requested exception is not an approved waiver.

Assumption A1 is that the supplied F2 impact statement remains valid; it is not independent dependency evidence. Unknown U1 is the exact browser and operating-system versions for both platforms. Unknown U2 is F3's dependency on the shared lookup on both platforms. Unknown U3 is the obligations review required by RA-7 v1. Unknown U4 is readiness of an authorized nonproduction environment and synthetic data for the required scope; no readiness evidence is supplied. These unknowns remain open, and required work remains blocked where its prerequisites are unresolved.

Proposed review roles, not assigned people, are a product representative for the release objective and explicit exclusion, an engineering representative for dependency impact and platform versions, a security representative for SEC-7 v2, an obligations owner for RA-7 v1 and a test lead to coordinate the boundary. Scope acceptance requires the product and test representatives plus the relevant engineering, security and obligations reviews, with exact versions and decisions recorded. No role has accepted the proposal. Document-editing permission does not confer this decision authority; scope acceptance is neither evidence of testing nor release approval.

Proposed Change Input

Proposed Change PC-1 retains every v1 source above and adds CR-7 v4 proposal, section B: include F2 mobile-web receipt download because the proposed change routes it through the changed generator. If accepted, SCP-19 proposed v2 moves only F2/P-M from Out to In. It removes no pair from In, leaves F1/P-D, F1/P-M, F2/P-D, F3/P-D and F3/P-M unchanged, and leaves all four unknowns open. A1 must be reassessed for the changed route; SEC-7 v2 would apply to the added pair. Product, engineering, security, obligations and test review are required. PC-1 has no accepted owner, estimate, approval date or waiver, and v2 is not an accepted baseline.

Build the Feature-and-Platform Boundary Table

Create one row for each feature/platform combination in the bounded cohort. Read every source clause before assigning a label, including explicit exclusions, cross-feature dependencies and obligations. Using only the release's feature list would miss the unresolved order-history impact in this packet.

Use three labels with distinct meanings. In means required in the proposed boundary, subject to the stated prerequisites. Out means explicitly excluded with a supplied rationale and pending or recorded acceptance. Clarify means evidence is insufficient to settle the boundary. It must not become a convenient substitute for Out when required information is missing.

Feature	Platform	Proposed v1 Boundary	Basis and Rationale	Readiness and Acceptance
F1: Address editing	P-D: Chrome / Windows	In	CR-7 v3 A changes validation; SEC-7 v2 owner-only checks apply.	U1, U3 and U4 open; blocked; not accepted.
F1: Address editing	P-M: Safari / iOS	In	CR-7 v3 A changes validation; SEC-7 v2 owner-only checks apply.	U1, U3 and U4 open; blocked; not accepted.
F2: Receipt download	P-D: Chrome / Windows	In	CR-7 v3 B changes receipt generation; SEC-7 v2 owner-only checks apply.	U1, U3 and U4 open; blocked; not accepted.
F2: Receipt download	P-M: Safari / iOS	Out	CR-7 v3 B explicitly excludes the unchanged path; supplied impact says no changed-generator dependency. A1 remains an assumption.	Exclusion review pending; residual mobile receipt risk remains.
F3: Order history	P-D: Chrome / Windows	Clarify	CR-7 v3 C leaves the shared-lookup dependency unknown; U2 requires engineering review.	U1 through U4 open; blocked; not accepted.
F3: Order history	P-M: Safari / iOS	Clarify	CR-7 v3 C leaves the shared-lookup dependency unknown; U2 requires engineering review.	U1 through U4 open; blocked; not accepted.

The F2 mobile exclusion has residual risk: mobile receipt defects may remain undiscovered, and an incorrect impact statement would undermine its rationale. Recording that risk does not establish its acceptability. Ask the relevant reviewers to assess the exclusion and A1 rather than presenting the supplied statement as independent proof.

The table expresses a testing boundary, not a product-support matrix. SUP-7 v1 declares every combination supported. Nor does the table imply full requirement coverage: it identifies the relevant boundary and open decisions without enumerating all test conditions or demonstrating any execution.

Resolve Unknowns Before Seeking Acceptance

Keep the unknowns beside the scope so reviewers cannot mistake a polished table for a ready baseline. U1 needs engineering clarification of exact browser and operating-system versions. “Latest” would introduce a moving target absent from the packet. U2 needs dependency evidence for both order-history paths. U3 needs the obligations owner's review, not an invented list of regulations. U4 needs evidence of authorized environment and synthetic-data readiness, coordinated by the proposed test lead with the relevant owners.

These are proposed responsibilities, not accepted assignments. If a person has not taken ownership, record that explicitly and request an accountable reviewer. Do not add a fictitious due date or optimistic readiness claim to make the document appear complete. When evidence contradicts the proposed boundary, preserve the old source and record a correction or change proposal.

A useful acceptance record identifies the exact scope version and basis revisions, the included and excluded pairs, resolved questions, remaining constraints, the authorized decision-makers and their actual decisions. Record a date only when that review occurs. In this example, U1-U4 remain unresolved and no role has accepted the proposal, so neither v1 nor proposed v2 is an accepted baseline.

Acceptance concerns the agreed boundary and its implications. It does not mean tests were performed, requirements passed or the release was approved. Permission to edit a shared document is also insufficient: the person recording a decision may be different from the stakeholder authorized to make it.

Record Scope Changes Without Rewriting History

Keep a change log connected to the versioned source rather than replacing the table silently. A change request should say what new evidence or requirement changed the boundary, which exact pairs move, which assumptions become unreliable and which reviewers must decide. Estimates can follow an impact assessment; an unknown estimate should remain unknown.

For the single proposed entry PC-1, retain SCP-19 v1 and CR-7 v3, add CR-7 v4 proposal, and describe the candidate as SCP-19 proposed v2. Its membership delta adds F2/P-M to In and removes F2/P-M from Out. Nothing is removed from In. The unchanged pairs are F1/P-D, F1/P-M, F2/P-D, F3/P-D and F3/P-M; both F3 pairs stay Clarify.

The reason is the proposed mobile route through the changed generator. Reassess A1 and extend SEC-7 v2 owner-only checks to the added pair if the change is accepted. U1-U4 remain open. The entry's decision state is pending product, engineering, security, obligations and test review, with owner, estimate and approval date unconfirmed. It records no approved waiver.

Until those decisions are made, do not label v2 approved or claim the testing records were updated. A scope change describes proposed work; changing test cases or executing them would require separate authorized actions and evidence.

Use the Boundary in the Next Review

Before requesting acceptance, check that the artifact answers these questions:

• Which release, objective and versioned sources does this boundary describe?
• Does every feature/platform pair have an explicit decision, reason and traceable basis?
• Are required obligations retained, exclusions explained and unresolved dependencies visible?
• Who can decide, what has actually been accepted and what would reopen that decision?

For Parcel Desk, the next useful action is to resolve the four unknowns and review the sole explicit exclusion before seeking acceptance. Keep required-but-blocked work visible instead of shrinking the boundary to match today's environment. That leaves stakeholders with a decision they can examine, rather than a scope label that promises testing nobody has performed.