Test Plan Writer

Purpose

Create an actionable test plan tailored to the change.

Core Principles

1. Scope validation by user impact, not just implementation details.
2. Separate automated checks from manual validation.
3. Cover both success and failure flows.
4. Prioritize paths with the highest regression risk.
5. Include visual validation whenever the UI changes.
6. Decide in advance what evidence will prove validation, such as command output, logs, or screenshots.

Inputs

• Change summary
• Affected files or modules
• User impact or risk
• Available test tools or environment details, if available

Workflow

1. Identify the user flows and system paths affected by the change.
2. Pull out the highest-risk scenarios first.
3. Separate what can be covered by automated tests from what needs manual validation.
4. Add failure, exception, permission, and boundary-value cases.
5. Include regression checks for existing behavior.
6. Document what evidence should be captured from validation.

Output Format

Test Goal

• Behavior this validation is meant to protect

Impact Scope

• User flows
• System or module impact

Priority

• High: scenarios that must be checked
• Medium: scenarios that should be checked if possible
• Low: scenarios to check if time allows

Automated Validation

• Commands to run
• Test types to cover
• Expected result

Manual Validation

• Core scenarios
• Failure or exception scenarios
• Permission or boundary-value scenarios

Regression Checks

• Existing areas that need rechecking
• Related feature checkpoints

Visual Validation

• Screen states to inspect
• Screenshots or other evidence to capture

Preconditions

• Required data
• Required accounts or permissions
• Environment variables or setup steps

Exit Criteria

• What must pass to consider validation complete
• Residual risks that remain

When Information Is Missing

• Draft the most complete test plan possible with the available context.
• Split missing environment details into explicit assumptions.
• Limit follow-up questions to three.