qa-acceptance

Topics in the source

• QA Acceptance
• When to use
• When not to use
• Acceptance criteria format
• What every plan must cover
• Evidence
• Quarantine and follow-up
• Handoff back to the author

Write acceptance criteria that a reviewer can run against the running app and decide pass or fail without asking the author. The criteria are the contract — automated tests cover correctness, QA covers feature-level behavior. A feature change is heading to QA and needs a written validation plan. A reviewer is asked to verify a PR that touches user-visible behavior. An incident postmortem requires a regression check before reopen-prevention. A release candidate needs a pre-cut smoke pass. The change is unit-test-only (utility refactor, internal naming). Acceptance criteria are unnecessary churn. You are asked to write tests against API contracts. Use contract testing, not feature QA. Each criterion is a single, independently-verifiable statement: Example: Avoid criteria that combine multiple whens or thens. Split them. 1. Golden path. The most common successful flow, end to end. 2. Empty and minimum states. Zero items, one item, missing optional inputs. 3. Boundary inputs. Max length strings, max numeric values, unicode, RTL text where applicable. 4. Error states. Network failure, permission denied, validation failures, conflict (409), not found (404). 5. Concurrency and ordering. T

This is an excerpt. Refer to the complete source and its current requirements.