SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillstest-scenarios

test-scenarios

Testing & quality

View repository

Updated 10-15 17:28

About this skill

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)

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

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.

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