Test Scope Analysis
Use it to define explainable boundaries for an iteration, release, change, or risk review.
StatusStable
TypeAtomic Skill
DomainSoftware testing
SDLCTest design
Good forQA / PM
LanguageChinese / English
EvalsEvals ✓
Synced2026-09-15
Why this Skill
It turns this Skill's method into a quality input that can be executed, reviewed, and reused.
- Do not generate a full test strategy, choose a concrete executable set, or execute tests.
- Do not use changed-file names, test names, scope tables, or static checks as coverage/pass evidence.
- Each TS-## includes goal/object, included, excluded, rationale, depth, platform/role/data/environment dependencies, stop conditions, expansion triggers, residual risk, source, and owner.
- Treating “test only the core flow” as proof that non-core paths are safe.
When to use
Use this Skill
- Use it to define explainable boundaries for an iteration, release, change, or risk review.
- Use it to make core journeys, direct/transitive impact, non-functional scope, migration compatibility, and unassessed areas explicit.
- Use it when context is incomplete but a bounded scope draft and evidence questions are useful.
Common pitfalls
- Treating “test only the core flow” as proof that non-core paths are safe.
- Replacing scope rationale and risk evidence with test or file counts.
- Having no expansion trigger when change or risk evidence evolves.
Input
Minimum Input
- Read `prompts/test-scope-analysis.md` and audit objective, version, scope, risk, and constraints.
Recommended Input
- Project goal
- Test scope
- Constraints
Optional Context
- Relevant code or configuration
- Historical results
- Logs and metrics
Output
The output follows this Skill's method and makes facts, assumptions, risks, and next steps explicit.
These are the Skill's expected output requirements, not evidence that it ran in a real project.
- 01Read prompts/test-scope-analysis.md and audit objective, version, scope, risk, and constraints.
- 02Classify input as known, missing, conflicting, stale, out_of_scope, and assumptions.
- 03Record inclusion, exclusion, depth, dependencies, stop conditions, expansion triggers, evidence, and owner role in TS-## entries.
- 04Separate scope facts, risk inferences, recommendations, and Human decisions; give a verifiable reason for every tradeoff.
View full output structure
- 05Deliver a bounded scope and expansion criteria when context is missing; never upgrade a scope statement into coverage proof.
How It Works
- 01Read prompts/test-scope-analysis.md and audit objective, version, scope, risk, and constraints.
- 02Classify input as known, missing, conflicting, stale, out_of_scope, and assumptions.
- 03Record inclusion, exclusion, depth, dependencies, stop conditions, expansion triggers, evidence, and owner role in TS-## entries.
- 04Separate scope facts, risk inferences, recommendations, and Human decisions; give a verifiable reason for every tradeoff.
- 05Deliver a bounded scope and expansion criteria when context is missing; never upgrade a scope statement into coverage proof.
Install & Quick Start
Install command / SHELL
npx skills add \
https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/test-scope-analysis
-gtest-scope-analysis.prompt
@skill test-scope-analysis
Using the current project context, produce an actionable result following this Skill.
Additional context:
[Paste project context or requirement]---
name: test-scope-analysis
description: Use this skill when a test activity, iteration, release, or risk review needs explicit inclusion, exclusion, depth, and expansion boundaries before execution; triggers include test scope analysis, test boundary review, and release test scoping.
---
# Test Scope Analysis
Analyze goals, product surface, changes/risks, constraints, existing assets, platforms, roles, data, and environments before testing. Produce `TS-##` inclusion/exclusion, depth, dependencies, stop conditions, expansion triggers, and residual risk. This is not a full test strategy, test selection, or test execution.
## When to Use
- Use it to define explainable boundaries for an iteration, release, change, or risk review.
- Use it to make core journeys, direct/transitive impact, non-functional scope, migration compatibility, and unassessed areas explicit.
- Use it when context is incomplete but a bounded scope draft and evidence questions are useful.
Do not use it to execute tests, generate a complete strategy, or claim full coverage/zero risk without evidence.
## Output Format Options
- Use Markdown by default; when a table, CSV, or JSON is requested, preserve the same evidence, status, impact, owner, and validation fields.
- Do not present a structured format or static inventory as execution, pass, approval, or release evidence.
## How to Use
1. Read this Skill's primary prompt and provide the objective, scope, material, environment, and available evidence.
2. Follow the prompt's input audit and output contract; deliver a bounded first pass when information is incomplete.
3. Retain source, evidence status, impact, owner role, close condition, and validation method for every finding.
## Workflow
1. Read `prompts/test-scope-analysis.md` and audit objective, version, scope, risk, and constraints.
2. Classify input as `known`, `missing`, `conflicting`, `stale`, `out_of_scope`, and `assumptions`.
3. Record inclusion, exclusion, depth, dependencies, stop conditions, expansion triggers, evidence, and owner role in `TS-##` entries.
4. Separate scope facts, risk inferences, recommendations, and Human decisions; give a verifiable reason for every tradeoff.
5. Deliver a bounded scope and expansion criteria when context is missing; never upgrade a scope statement into coverage proof.
## Core Constraints
- Do not generate a full test strategy, choose a concrete executable set, or execute tests.
- Do not use changed-file names, test names, scope tables, or static checks as coverage/pass evidence.
- Each `TS-##` includes goal/object, included, excluded, rationale, depth, platform/role/data/environment dependencies, stop conditions, expansion triggers, residual risk, source, and owner.
- Without risk, execution, or environment evidence, mark status `unassessed`, `unverified`, or `unexecuted`.
## Reference Files
- Always read `prompts/test-scope-analysis.md` before producing an analysis.
- For regression, read `evals/eval.yaml` and its cases; a scope draft does not prove testing ran.
- For trigger checks, use `evals/trigger-prompts.csv` and `evals/local-rules.json`; missing selection trace is `BLOCKED`.
## Best Practices
- Prioritize high-impact gaps with a verifiable next action, using the smallest useful experiment or evidence request.
- Separate facts, evidence-backed inferences, recommendations, and Human decisions; never upgrade an assumption into a conclusion.
## Delivery Checklist
- [ ] Record objective, version, scope, and six-part input audit.
- [ ] Give every `TS-##` inclusion/exclusion, depth, dependencies, stop, and expansion conditions.
- [ ] Cover core/transitive impact, non-functional, migration compatibility, and unassessed areas.
- [ ] Give each tradeoff source, impact, and validation method.
- [ ] Do not present a bounded scope as coverage proof, execution evidence, or release conclusion.
## Common Pitfalls
- Treating “test only the core flow” as proof that non-core paths are safe.
- Replacing scope rationale and risk evidence with test or file counts.
- Having no expansion trigger when change or risk evidence evolves.