Test Scope Analysis Skill: Make Inclusion, Exclusion, and Expansion Boundaries Explicit
A test scope is a decision about what the team will learn now and what it will leave uncertain. If exclusions and expansion triggers are hidden, a bounded check is easily mistaken for full coverage.
Why this Skill is needed
The Test Scope Analysis Skill analyzes goals, product surface, changes, risks, constraints, assets, platforms, roles, data, and environments before testing. It produces TS-## boundaries, not execution results.
What the Skill does
The scope should make uncertainty visible instead of hiding it behind a short test list.
Use this Skill to define explainable scope for an iteration, release, change, or risk review, including core journeys, direct and transitive impact, non-functional scope, compatibility, dependencies, and unassessed areas.
A good TS-## entry states included and excluded objects, rationale, depth, dependencies, stop conditions, expansion triggers, residual risk, source, and owner.
Use it when a release or test activity needs a bounded scope before anyone selects an executable set or reports coverage.
What it does not do
The Test Scope Analysis Skill can organize material, evidence, and next actions for Included scope. It does not replace:
- Confirmation of rules, scope, and risk by the accountable domain owner.
- A real environment, account, dataset, log, or run record; static analysis does not become runtime evidence by itself.
- Authorization for release, compliance, production actions, or residual-risk acceptance.
- A Human decision when supplied sources conflict.
What it checks
The value of this Skill is not another keyword list. It connects each focus area to an observable input, a judgment, and a way to close the loop. Start with a small matrix based on the source Skill’s output contract:
| Focus | Question before analysis | Handoff output |
|---|---|---|
| Included scope | Object, journey, platform, role, data, and depth | Rationale and source |
| Excluded scope | What is intentionally not assessed | Reason and risk |
| Expansion trigger | Evidence that makes scope grow | Observable condition |
| Residual risk | What remains unassessed or unexecuted | Owner and decision boundary |
If a row has only a conventional expectation and no source or validation method, keep it open instead of turning it into a pass.
Audit inputs before you start
Before analyzing Included scope, classify the input into six evidence states. A gap is not automatically a failure, but it must not disappear inside the conclusion.
| State | Meaning | How this Skill should handle it |
|---|---|---|
| known | Directly supported by the supplied material | Keep the source, version, and time with the judgment |
| missing | Needed for this pass but not supplied | Name the smallest evidence action and limit the conclusion |
| conflicting | Sources disagree | Show both sources and route the conflict to an owner |
| stale | Present but outside the relevant version or time window | Mark freshness; old evidence is not current proof |
| out_of_scope | Related but excluded from this pass | Keep the boundary explicit |
| assumptions | Temporarily adopted to continue analysis | State how and when the assumption will be checked |
Keep the input version, scope, environment, evidence locations, and accountable owner together. Without a run record, deliver analysis, design, or a validation plan—not an execution pass.
From problem to structured Finding
Connect the source, scope, evidence state, analysis, owner, action, close condition, and validation before writing the conclusion. The case below keeps this Skill’s identifier and domain context.
Keep the decision layers separate
For Included scope, do not compress four different kinds of language into “recommended to pass”:
| Layer | How to write it | Application here |
|---|---|---|
| Fact | What the supplied material directly shows | Cite the source, version, input, or run record for the focus |
| Evidence-backed Inference | What several facts support together | Show the inference chain and retain uncertainty |
| Recommendation | The smallest next action | Name the evidence, review, execution, or regression path |
| Human Decision | What an accountable person must decide | Leave scope, risk acceptance, resources, and release meaning to the owner |
A complete case
This case follows Input, Analysis, Finding, Decision, and Validation. When material is incomplete, keep missing, conflicting, or assumptions visible instead of turning them into a pass.
Input
| Material | What to provide | What to do when it is missing |
|---|---|---|
| Goal and product surface | Release objective, journeys, components, platforms, roles, and data | Keep missing surface explicit |
| Change and risk | Direct and transitive impact, failure modes, defects, and non-functional concerns | Do not rely only on changed filenames |
| Constraints and assets | Time, environments, test data, existing tests, and dependencies | Record blockers |
| Decision boundary | Owner, residual-risk accepter, stop and expansion rule | Do not claim full coverage |
Use a request like this:
Use the test-scope-analysis Skill.
Task: Define test scope for a release that changes account deletion and notification preferences.
Inputs: [release brief, dependency map, user journeys, platform matrix, risks, defects, environments, data limits]
Scope: [web and mobile, self-service deletion, notification events]
Constraints: [one staging environment and a fixed validation window]
Produce TS-## inclusion, exclusion, depth, dependencies, stop conditions, expansion triggers, evidence, owner, and residual risk. Do not execute tests or claim full coverage.Analysis
Use the input, matrix, and evidence state to form the judgment before writing the Finding; keep missing material as a gap.
Finding
Focused example: Scope account deletion without hiding mobile risk
The release brief changes deletion on web, but the same API serves mobile. The Skill should include the shared API and mobile confirmation behavior or record the exclusion with an expansion trigger tied to API changes or deletion defects. It should not call a web-only pass full coverage.
Scope analysis explains boundaries and trade-offs. It cannot prove tests ran, coverage is complete, risk is zero, or release is approved.
Example finding: turn one problem into a handoff
The field example below shows the recording pattern; it is not an execution result.
If the supplied material cannot prove that Included scope meets its contract, write the finding like this. It does not invent the missing rule or turn missing evidence into a failure.
| Field | Example wording |
|---|---|
| Source and scope | Record the requirement, version, environment, and the concrete object for Included scope |
| Finding | The condition or result for Included scope is not yet traceable to evidence |
| Evidence state | missing / assumptions; use conflicting when sources disagree |
| Impact and priority | Name the affected user, journey, or delivery decision without inflating severity |
| Owner and Human decision | Ask the product, engineering, security, or test owner to confirm the rule and trade-off |
| Action and close condition | Add the smallest missing evidence; close only when source, judgment, and owner can be reviewed |
| Validation | Name one repeatable check, query, or run and retain the raw artifact |
The point is to let the next person walk from the finding back to the source and run an action that can change the decision.
Decision
The accountable owner confirms the decision question and risk trade-off; the Skill does not make that choice.
Validation
Before closing the finding, run the stated validation and retain the raw artifact. Without an execution record, the status remains unverified.
How a Finding enters the next stage
Handoff output
| Output field | Why it exists | Example status |
|---|---|---|
| Included scope | Object, journey, platform, role, data, and depth | Rationale and source |
| Excluded scope | What is intentionally not assessed | Reason and risk |
| Expansion trigger | Evidence that makes scope grow | Observable condition |
| Residual risk | What remains unassessed or unexecuted | Owner and decision boundary |
Every conclusion should point to a source, evidence state, and next action. If evidence is missing, use pending, blocked, unassessed, or NOT_SCORED instead of filling the gap with confidence.
Next-stage route
At minimum, hand off the source, evidence state, owner, close condition, and validation action; the next-stage conclusion remains bounded by the evidence state.
How to prepare better input
Provide the goal, versions, product surface, direct and transitive changes, risks, constraints, platforms, roles, data, environments, existing assets, and residual-risk owner. Missing context stays unassessed.
A useful handoff includes input versions, scope, time window, evidence index, assumptions, Human decision boundary, and the smallest validation action.
Working with other Skills
- Risk-Based Testing:uses risk to justify depth and trade-offs.
- Requirement Traceability Analysis:connects scope to obligations and evidence.
- UI Test Strategy:deepens journey, state, and platform boundaries.
Common traps
- Using changed-file names or scope tables as proof of coverage.
- Excluding transitive dependencies without a rationale or expansion trigger.
- Writing a full strategy or executable set when only scope analysis was requested.
Install and invoke
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/test-scope-analysis -gUse the test-scope-analysis Skill.
Include objective, scope, versions, evidence paths, constraints, and decision boundary.
Audit inputs first, preserve evidence states, and finish with owner, close condition, and validation method.FAQ
Is exclusion the same as not important?
No. It means not assessed in this activity; the reason, residual risk, and expansion trigger must remain visible.
Can this Skill choose the exact test IDs?
No. It defines the boundary and depth rationale; executable selection is a separate activity.
The Skill is most useful when attached to one real project artifact and kept with its source evidence. Start narrow, validate the uncertain part, and expand only when evidence supports it.
References
Source Skill and execution contract
The complete execution contract lives in Test Scope Analysis prompt. The source directory may also contain evaluation cases and supporting material.
Static plans, file presence, and dry runs keep their evidence state. They do not become runtime proof, an all-passed claim, or release approval.
Reference links
- Test Scope Analysis prompt:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/test-scope-analysis/prompts/test-scope-analysis.md
- Test Scope Analysis Skill source:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/test-scope-analysis
- Test Scope Analysis details:https://inaodeng.com/en/qaskills/test-scope-analysis/
- Awesome QA Skills on GitHub:https://github.com/naodeng/awesome-qa-skills