functional-testinglisted

# Functional Testing ## Purpose Verify the system does what it's supposed to do, per requirements/acceptance criteria — as opposed to non-functional concerns (performance, security, accessibility, which have their own skills). ## Workflow 1. **Extract acceptance criteria** from the spec/ticket. If none exist, derive them from the UI/PRD and confirm with the user before testing against assumptions. 2. **Map the happy path** first — the primary flow the feature exists for. 3. **Enumerate alternate flows** — every branch, conditional, optional field, toggle. 4. **Enumerate negative flows** — invalid input, missing required fields, unauthorized actions, expired tokens. 5. **Cross-check business rules**, not just UI behavior: does a discount actually apply to the order total in the DB, not just render a strikethrough price? ## CRUD feature checklist For any Create/Read/Update/Delete surface: - **Create**: required-field validation, duplicate handling, default values, success feedback, record actually persisted (verify via API/DB, not just toast message). - **Read**: pagination edges (page 0, last page, empty list), sorting/filtering combinations, stale-data-after-mutation. - **Update**: partial updates, concurrent-edit conflicts, optimistic UI vs. actual persisted state, validation re-applied on edit. - **Delete**: soft vs hard delete, cascading effects (does deleting a parent orphan children?), confirmation dialogs, undo if offered, permissions. ## Form testing checklist - Re