qalisted

# QA Patterns Scenario-based acceptance testing methodology. Ensures implementations satisfy user-observable requirements beyond what unit tests cover. ## Iron Law > **VERIFY BEHAVIOR FROM THE USER'S PERSPECTIVE** [1][2] > > Test what the user asked for, not implementation details. Every acceptance criterion > gets at least one scenario. Every scenario produces observable evidence. If you can't > demonstrate it works from the outside, it doesn't work. [3][8] --- ## Scenario Types [1][2][6] Five categories ensure comprehensive coverage: | Type | Purpose | Example | |------|---------|---------| | **Happy path** | Core functionality works as described | "Add item → item appears in list" | | **Boundary/edge** | Limits, empty, maximum, minimum values | "Add item with 1000-char name → truncated or rejected" | | **Negative path** | Invalid inputs, missing permissions, errors | "Add item without auth → 401 returned" | | **Integration** | Components work together correctly | "Add item → appears in search results" | | **Regression** | Existing behavior preserved after changes | "Old items still load after schema migration" | **Minimum coverage**: At least one scenario per acceptance criterion. At least one boundary and one negative scenario per feature. [1][6] ## Scenario Design from Acceptance Criteria [4][8][9] Extract testable claims using Given/When/Then: ``` Acceptance criterion: "Users can upload files up to 10MB" S1 (happy): Given auth user, When upload 5MB file,