qa-acceptance

Write each criterion as a single Given/When/Then statement describing starting state, action, and observable outcome. Cover the golden path, empty states, boundary inputs, error states, concurrency, performance, backward compatibility, and telemetry, marking non-applicable sections explicitly.

A validation plan should include the golden path flow, empty and minimum states, boundary inputs like max-length strings and unicode, error states such as network failure and 404s, concurrency scenarios, performance envelope, backward compatibility, and telemetry checks.

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 in 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 is not auditable and does not count.

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.