Build a QA checklist for a specific change

A change-focused checklist should cover the behavior affected and plausible regressions. Avoid a giant generic list that hides the important checks.

Use a reviewable project copy

Give the product or code teammate the relevant specification and a dedicated project folder or branch. Separate a proposed change from permission to release it. Request a diff or evidence table alongside the recommendation, and run checks that exercise the behavior in question. Generated code and test output still need review in the actual project environment.

Inputs for this workflow: Change description, affected screens and known risks.

Work through the task

1. Trace inputs to changed outputs.
2. Choose representative success, failure and boundary cases.

A brief you can adapt

Write qa-plan.md with setup, steps, expected result and evidence to collect. Mark checks requiring unavailable environments.

The filenames above are examples. Replace them with your actual inputs and destination before submitting the task.

Review the deliverable

Run the highest-risk cases and record observed outcomes rather than checking boxes from memory.

Where this approach can fail

A test plan is not a test result. Keep planned and executed checks clearly separate.

For the related desktop setup, see local folder.