test-scenarios
Generate complete test scenario coverage from a feature spec: happy paths, edge cases, error handling, accessibility, security, and performance scenarios. Includes a coverage analyzer that flags gaps before QA writes the test plan. Distinct from automated test generation — this is the WHAT to test before HOW.
What this skill does
# 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) ## Workflow ### Step 1 — Spec read Read the PRD / user story / acceptance criteria. Identify: - User goals (what they want to do) - Inputs (what they provide) - Outputs (what they expect) - Side effects (what changes in the system) ### Step 2 — Happy path For each user goal, write the primary flow: - Preconditions - Steps - Expected result Aim for 1-3 happy paths per feature. ### Step 3 — Edge cases For each input, ask: - What's the empty value? - What's the minimum? - What's the maximum? - What's just below min / just above max? - What's the wrong type? - What's the weird-but-valid (very long, special chars, Unicode, emoji)? ### Step 4 — Error handling For each failure mode: - Network failure - Server error (5xx) - Validation error (4xx) - Timeout - Concurrent modification - Auth expired / lost For each: what does the user see? Recover-from / try-again UX? ### Step 5 — Empty / first-use / after-action states - First use (no data) - After delete (last item) - After error (partial state) - After timeout - After cancel ### Step 6 — Concurrent / race scenarios Two users simultaneously: - Editing same record - Triggering same action - Submitting same form - Reaching capacity limit ### Step 7 — Accessibility - Tab through with keyboard - Use with screen reader - High contrast / inverted colors - Reduced motion preference - Large text scaling - Voice control ### Step 8 — Security + privacy - Logged out user accesses - Unauthorized user accesses - Permission downgrade mid-action - PII handling - Injection attempts (XSS, SQLi) - Rate limiting ### Step 9 — Run `test_scenario_generator.py` Audit a candidate scenario list for category coverage; flag gaps. ```bash python3 project-management/execution/test-scenarios/scripts/test_scenario_generator.py \ --input feature_spec.json --format markdown ``` ## Decision frameworks ### How many scenarios per category? | Feature type | Happy | Edge | Error | Empty | Concur | A11y | Security | |--------------|-------|------|-------|-------|--------|------|----------| | Form / submission | 1-3 | 4-8 | 4-6 | 2 | 1-2 | 4 | 3-5 | | Browse / list | 2-3 | 3-5 | 2-3 | 2-3 | 1 | 3 | 2 | | Real-time / collab | 3 | 4-6 | 4-6 | 2 | 4-6 (essential) | 3 | 3 | | File upload | 2 | 6-10 (sizes/types) | 4-6 | 1 | 1-2 | 2 | 5+ (file abuse) | | Payment / financial | 3 | 6-10 | 8+ (critical) | 2 | 4-6 (idempotency!) | 3 | 8+ | | Bulk operation | 2 | 4-6 (sizes) | 4-6 | 1 | 2-4 (partial fail) | 2 | 3 | Adjust for risk profile of the specific feature. ### Risk-weighted scenario selection Not all scenarios need full QA coverage. Apply: - **Happy path:** always test - **Edge cases:** test those that matter (likelihood × severity) - **Error handling:** test all paths that user can recover from - **Empty state:** always test (first impression!) - **Concurrent:** test for data-integrity-critical features - **Accessibility:** baseline coverage on all UI; full coverage on user-facing - **Security:** scale with sensitivity (full coverage on auth/payment) ### Manual vs automated | Scenario type | Default | |----------------|---------| | Happy path | Automated (E2E or integration) | | Edge cases (input validation) | Unit tests | | Error handling | Mix (mocked errors in unit; real in integration) | | Empty state | Visual regression + manual | | Concurrent | Hard — usually manual + targeted integration | | Accessibility | Automated (axe-core) + manual screen-reader | | Security | SAST + DAST + manual review for critical paths | | Performance | Automated load tests | | Localization | Pseudo-localization + manual spot-check | ## Common engagements ### "Generate test scenarios for this new feature" 1. Read the PRD / spec. 2. Apply the 7 categories. 3. Generate scenarios; estimate count per category. 4. Run validator; address gaps. 5. Hand to QA for implementation. ### "Audit our test plan for completeness" 1. Categorize existing scenarios. 2. Identify under-covered categories. 3. Score by risk × likelihood. 4. Recommend additions. ### "Post-incident scenario gap analysis" 1. Pull the incident scenario. 2. Map: which category was missed? 3. Add scenario; verify regression coverage. 4. Update default-coverage rubric for that feature type. ## Anti-patterns to avoid - **Only happy paths.** Production fails on edges; you skipped them. - **No empty state.** First-use is broken. - **"QA will figure it out."** No, QA tests what's specified. - **Generic acceptance criteria.** "Should work" is not testable. - **No accessibility scenarios.** Excludes users; fails compliance. - **No security scenarios.** Vulnerable paths ship. - **No performance scenarios for performance-sensitive features.** Surprise at scale. - **Skipping concurrent for collaborative features.** Race conditions ship. ## References - `references/scenario-categories.md` — deep on the 7+ categories with examples - `references/coverage-anti-patterns.md` — common gaps + fixes ## Related skills - `project-management/execution/create-prd` — upstream spec - `project-management/execution/wwas` — acceptance criteria - `engineering/senior-qa` — implementation - `engineering/code-reviewer` — review coverage - `product-team/spec-to-repo` — translating spec to tickets
Related in Security
mac-ops
IncludedComprehensive macOS workstation operations — diagnose kernel panics, identify failing drives, audit launchd startup items, decode wake reasons, triage TCC permission denials, manage APFS snapshots, recover from no-boot. Use for: Mac is slow, slow bootup, won't boot, kernel panic, kernel_task hot, mds_stores CPU, photoanalysisd, cloudd, login loop, gray screen, sleep wake failure, drive failing, IO errors, APFS snapshots eating space, Time Machine local snapshots, Spotlight indexing, launchd, LaunchAgent, LaunchDaemon, login items, TCC permissions, Full Disk Access, Screen Recording denied, Gatekeeper, quarantine, com.apple.quarantine, app is damaged, helper tool, /Library/PrivilegedHelperTools, pmset, wake reasons, dark wake, sysdiagnose, panic.ips, DiagnosticReports, configuration profile, MDM profile, remote diagnostics over SSH.
a11y-audit
IncludedRun accessibility audits on web projects combining automated scanning (axe-core, Lighthouse) with WCAG 2.1 AA compliance mapping, manual check guidance, and structured reporting. Output is configurable: markdown report only, markdown plus machine-readable JSON, or markdown plus issue tracker integration. Use this skill whenever the user mentions "accessibility audit", "a11y audit", "WCAG audit", "accessibility check", "compliance scan", or asks to check a web project for accessibility issues. Also trigger when the user wants to verify WCAG conformance or map findings to a specific standard (CAN-ASC-6.2, EN 301 549, ADA/AODA).
erpclaw
IncludedAI-native ERP system with self-extending OS. Full accounting, invoicing, inventory, purchasing, tax, billing, HR, payroll, advanced accounting (ASC 606/842, intercompany, consolidation), and financial reporting. 413 actions across 14 domains, 43 expansion modules. Constitutional guardrails, adversarial audit, schema migration. Double-entry GL, immutable audit trail, US GAAP.
assess
IncludedAssesses and rates quality 0-10 across multiple dimensions (correctness, maintainability, security, performance, testability, simplicity) with pros/cons analysis. Compares against project conventions and prior decisions from memory. Produces structured evaluation reports with actionable improvement suggestions. Use when evaluating code, designs, architectures, or comparing alternative approaches.
spring-boot-security-jwt
IncludedProvides JWT authentication and authorization patterns for Spring Boot 3.5.x covering token generation with JJWT, Bearer/cookie authentication, database/OAuth2 integration, and RBAC/permission-based access control using Spring Security 6.x. Use when implementing authentication or authorization in Spring Boot applications.
code-hardcode-audit
IncludedDetect hardcoded values, magic numbers, and leaked secrets. TRIGGERS - hardcode audit, magic numbers, PLR2004, secret scanning.