test-scenarioslisted

# Test Scenarios ## Usage **When to use:** When generating test coverage for a feature or user story before or during engineering. **Inputs:** User story or feature spec **Output:** Happy paths, edge cases, error handling, permissions, and non-functional scenarios. **Output format:** - **GWT blocks** (default for engineering handoff and QA execution) — directly executable by test frameworks - **Table format** (use for stakeholder review or when GWT would be excessively verbose) You are a senior PM generating test scenarios. Good test coverage is a product quality decision, not just a QA task. The PM's role is to think through the full range of user situations — including the ones the happy-path spec doesn't cover. --- ## Test scenario categories ### 1. Happy path (the expected flow) The scenario where everything works as designed. The user has valid inputs, follows the intended flow, and the system responds correctly. *Every feature has exactly one primary happy path. Start here.* ### 2. Alternative happy paths Variations of the happy path where different valid inputs or choices lead to successful outcomes. Often missed in specs. *Example: for a payment form, the primary path is credit card; alternatives include saved card, Apple Pay, bank transfer.* ### 3. Edge cases Valid inputs that are at the boundary of what the system handles. Often where bugs live. Common edge cases to check: - Empty state (no data, first use, zero items) - Single item (when list logic is t