test-strategy-review

Test Strategy Review (Chinese Version)

When to Use

• A draft test strategy already exists and needs to be judged for whether it is sufficient, executable, and consistent with business and technical constraints.
• The review needs to distinguish blocking gaps, conditional items that can be completed within a time limit, and non-blocking improvements.
• There are conflicts among requirements, role analysis, technical descriptions, or project constraints, and traceable AI recommendations need to be formed for Human decision-making.

Inputs

The test strategy to be reviewed must be provided. Combine the requirements, role analysis, technical constraints, and project constraints provided by the caller; materials not provided are recorded as gaps and must not be fabricated. Preserve locatable document numbers, sources, and responsible persons.

Execution Process

1. Read and fully follow prompts/test-strategy-review.md; this Prompt is an independent execution specification.
2. Validate the strategy body and sources, and record missing items and conflicts; if there is no reviewable strategy, stop the substantive review.
3. Review item by item business coverage, test depth, executability, environment, data, quality gates, dependencies, and explicit exclusions.
4. Classify findings into blocking items and non-blocking items; further mark non-blocking items as conditional items that must be closed within a time limit or optional improvements.
5. Generate according to deterministic rules pass、conditional_pass or reject AI-assisted recommendations, and provide responsibility attribution and verifiable revision requests for gaps.
6. Perform self-checks on evidence, scope, responsible persons, conclusions, and Human decision boundaries.

Decision Constraints

• If any blocking item exists, only recommend reject。
• If there are no blocking items but there are conditional items that must be closed before a specified gate, recommend conditional_pass。
• If there are no blocking items and no conditional items, recommend pass; non-blocking improvements that do not affect the recommendation may be retained.
• If source conflicts affect scope, key risks, gates, or exclusions and remain unresolved, they are treated as blocking; one side must not be chosen on one's own.
• Responsible persons are taken only from the input. If not provided, write "to be assigned", and make assigning a responsible person a revision request.
• The strategy describes a plan, not tests already executed; test results, evidence, risk acceptance, waivers, or approvals must not be fabricated.
• The output is always marked as AI-assisted recommendation. Human retains the final decision-making authority for pass、conditional_pass or reject ; it must not be claimed that final approval has occurred.

Output Contract

Output in sequence:Review status, inputs and conflicts, dimensional review matrix, blocking items, non-blocking items, revision requests, exclusion review, basis and limitations for the recommendation, questions pending Human decision. Each finding and revision request should cite evidence, explain impact, preserve existing responsible persons, and give verifiable closure conditions.

Load as Needed

• Read on every execution prompts/test-strategy-review.md, using the input validation, eight-dimensional check, classification rules, and output structure therein.
• Read only when evaluating or regressing this Skill evals/; the scenarios therein are not actual project evidence.

Pre-delivery Self-check

• All eight review dimensions have evidence, gaps, or not-applicable notes
• Blocking items and non-blocking items have been partitioned, and conditional items have not been mixed into optional improvements
• Recommended values strictly match the classification rules; schedule pressure was not used to cover quality gaps
• All sources of conflict are retained; no unauthorized decisions were made and no changes/exemptions were fabricated
• Each revision request has an object, an owner or "to be assigned", a time point/threshold, and closure evidence
• The output is clearly an AI-assisted recommendation; the final Human decision remains pending

Common Misconceptions

• Do not judge completeness by the length of the strategy; check whether key risks are truly mapped to tests and gates.
• Do not treat "the environment can be dealt with later" as a minor issue; missing environment capabilities may make key tests unexecutable.
• Do not automatically regard explicit exclusions as reasonable; they need to be consistent with the approved scope, risk treatment, and sources.
• Do not treat conditional_pass as a vague compromise; each condition must be assignable, verifiable, and have a closure threshold.