When a bug's root cause is insufficient test coverage, don't just write a regression test for that one bug. Step back and brainstorm test cases across the entire feature area that could uncover similar bugs.
Trigger
Use this skill when:
- A bug was found that would have been caught by better tests
- A feature area feels under-tested after an incident
- You want to proactively harden a feature before release
- A code review reveals a gap and you want to find others like it
Process
1. Understand the bug
Before brainstorming, understand what went wrong:
- What was the bug?
- What category does it fall into? (state management, data flow, validation, race condition, edge case, integration boundary, etc.)
- Why didn't existing tests catch it?
- What assumption was wrong?
2. Map the feature area
Trace the full scope of the feature:
- Entry points: All ways users/systems trigger this feature (UI actions, API calls, events, scheduled jobs)
- State transitions: Every state the feature can be in and how it moves between them
- Data flow: Where data comes from, how it transforms, where it goes
- Integration boundaries: External services, databases, queues, caches, other modules
- Configuration: Feature flags, settings, environment-dependent behavior
3. Brainstorm by category
For each category below, generate concrete test cases. Not every category applies to every bug — focus on the categories most relevant to the bug pattern discovered.
Happy path gaps
- Are all primary user flows tested end-to-end?
- Are success cases tested with realistic data, not just minimal fixtures?
Edge cases and boundary conditions
- Empty/null/undefined inputs
- Maximum and minimum values
- Single-item vs. multi-item collections
- First-time vs. repeated operations
- Exactly-at-boundary values (off-by-one)
State and ordering
- Operations performed out of expected order
- Concurrent/parallel operations on the same resource
- Operations during in-progress state transitions
- Stale state after external changes
- Retry after partial failure
Error and failure modes
- Network failures, timeouts, partial responses
- Invalid or malformed data from external sources
- Permission/authorization edge cases
- Rate limits and resource exhaustion
- Graceful degradation when dependencies are down
Data integrity
- Data consistency after create/update/delete sequences
- Referential integrity across related entities
- Idempotency of operations that should be idempotent
- Data migration and schema evolution scenarios
Integration boundaries
- Contract mismatches between producer and consumer
- Behavior when upstream service changes response shape
- Cache invalidation and staleness
- Event ordering and delivery guarantees
Time and scheduling
- Timezone handling
- Daylight saving transitions
- Operations spanning midnight/month/year boundaries
- Expiration and TTL behavior
- Clock skew between services
User-facing behavior
- Loading, error, and empty states in the UI
- Accessibility under all states
- Behavior after page refresh / navigation / back button
- Multi-tab or multi-device scenarios
4. Prioritize
Rank the brainstormed test cases by:
- Likelihood — How probable is this scenario in production?
- Impact — How bad is it if this breaks?
- Similarity to the original bug — Same category of root cause?
Focus on high-likelihood + high-impact cases first. Tests that match the same root cause pattern as the original bug get priority — if the bug was a state management issue, other state management tests are most likely to find siblings.
5. Output format
Present results as a prioritized checklist:
## Test Brainstorm: [Feature Area]
### Original Bug
- **Bug**: [brief description]
- **Root cause**: [why it happened]
- **Category**: [e.g., state management, validation, race condition]
### Priority 1 — Same root cause pattern
- [ ] [Test case description] — [why this could fail the same way]
- [ ] ...
### Priority 2 — High likelihood + high impact
- [ ] [Test case description]
- [ ] ...
### Priority 3 — Edge cases worth covering
- [ ] [Test case description]
- [ ] ...
Anti-patterns
- Don't just write a regression test for the exact bug and stop. The goal is to find the family of bugs, not just the one you already know about.
- Don't generate a wall of 50 generic test ideas. Every test case should be specific to this feature area and actionable.
- Don't ignore the test pyramid. Some brainstormed cases are best as unit tests, others as integration tests, others as e2e. Note the appropriate level.
- Don't brainstorm without implementing. The output should feed directly into writing actual tests. Pick the top items and write them.