Test Scenarios

Test Scenarios

Generate complete scenario coverage from a feature spec before tests are written. Closes the gap between "we built it" and "it survives production."

When to use this skill

• After PRD approval but before engineering implementation
• During sprint planning to size testing effort
• During code review to verify test coverage
• During QA planning to scope test pass
• During bug-bash prep
• After a production incident to validate scenario gaps

The 7 scenario categories

For every feature, generate scenarios across:

1. Happy paths — primary user goals achieved cleanly
2. Edge cases — boundary conditions, unusual inputs
3. Error handling — what users see when things go wrong
4. Empty states — first-use, no data, after-delete
5. Concurrent operations — race conditions, optimistic locking
6. Accessibility — keyboard nav, screen reader, contrast, motion
7. Security + privacy — auth, permissions, PII, injection

Plus when applicable:

• Performance scenarios (load, latency, throughput)
• Localization (RTL, long-string, currency, date format)
• Cross-platform (browsers, devices, OS versions)

Clarify First

Before generating scenarios, confirm these inputs. If any is unknown or vague, ASK — do not assume:

• Feature type — form, browse/list, real-time/collab, file upload, payment, or bulk operation (drives the scenario count per category in the coverage rubric)
• Risk / sensitivity profile — auth, payment, or PII involved (scales up security and concurrency coverage in the risk-weighted selection)
• The spec's inputs, outputs, and side effects — what users provide, expect, and what changes in the system (drives edge cases in Step 3 and error handling in Step 4)