qa-acceptance

Write each acceptance criterion as a single Given/When/Then statement describing an observable outcome, such as what the UI shows after an action. Keep each criterion independently verifiable and avoid combining multiple actions or outcomes into one line.

A validation plan should cover the golden path, empty and minimum states, boundary inputs, error states like network failure and 404s, concurrency, performance limits, backward compatibility, and telemetry. Mark genuinely inapplicable sections as N/A with a reason rather than omitting them.

Skip acceptance criteria for unit-test-only changes like utility refactors or internal renames, where they add churn without value. Also avoid them for API contract verification, which belongs to contract testing rather than feature-level QA.

Each criterion needs concrete evidence: screenshots or clips for UI behavior, console or network output for API behavior, log snippets for telemetry, and timing measurements for performance. A pass without evidence cannot be audited by reviewers.

A failing criterion blocks acceptance unless the owner explicitly waives it with a tracked follow-up issue. The validation report returns Pass, Fail, and Blocked sections to the author, who owns converting failures into fixes or accepted deferrals.