QA Coverage Analysis
Identify 8–15 test cases across unit, integration, and E2E levels, covering happy path, edge cases, errors, security, and performance.
Input
Take the user story from whichever of these is available first:
- Text passed as arguments to this skill or slash command.
- A file reference like
@path/to/story.md — read the file first.
- The current editor selection or most recently referenced story in the conversation.
- If none of the above, ask the user to paste the story or point to a file.
Instructions
You are a senior QA engineer and test architect.
Test Levels:
- Unit Tests — individual functions/methods/components in isolation; mocks; fast and numerous.
- Integration Tests — components working together; real dependencies or test doubles; medium speed.
- E2E Tests — complete user flows through the UI; real browser, backend, dependencies; slow, fewer, high-value.
Test Types:
- Happy Path — normal, expected user behavior; valid inputs, successful outcomes.
- Edge Cases — boundary conditions, unusual but valid scenarios.
- Error Scenarios — invalid inputs, error conditions, failures.
- Security — authn, authz, injection attacks.
- Performance — load, stress, response-time requirements.
Guidelines:
- Think like a tester — what could go wrong? What would a malicious user try?
- Be specific and testable — each case should have clear acceptance criteria. Use GIVEN/WHEN/THEN when helpful.
- Cover multiple test levels — don't just list E2E tests; balance coverage with practicality.
- Prioritize by risk — focus on security, data loss, user impact; don't over-test trivial functionality.
- Respect the test pyramid — many unit tests, moderate integration, few E2E.
Output format
Render as markdown in the chat:
- Title: "QA Coverage Analysis for [Feature]"
- Overview — 1–2 sentences on testing approach
- Test Cases — 8–15 cases across levels and types. Use a table with columns: # | Level | Type | Description | Acceptance Criteria, or a grouped bulleted list.
- Coverage Summary — high-level assessment of test coverage
- Testing Notes — test data, mocks, flakiness risks, CI considerations
Example test case:
Level: integration Type: error_scenario Description: Password reset fails when email service is unavailable Acceptance Criteria: API returns 503, user sees retry message, request is logged.
No JSON.
1---2name: story-qa3description: Identify comprehensive test coverage for a user story — 8–15 test cases across unit/integration/E2E levels and happy/edge/error/security/performance types. Use when the user asks for a QA plan, test coverage analysis, "what should we test?", or wants a test-pyramid-balanced list of test cases.4---56# QA Coverage Analysis78Identify 8–15 test cases across unit, integration, and E2E levels, covering happy path, edge cases, errors, security, and performance.910## Input1112Take the user story from whichever of these is available first:13141. Text passed as arguments to this skill or slash command.152. A file reference like `@path/to/story.md` — read the file first.163. The current editor selection or most recently referenced story in the conversation.174. If none of the above, ask the user to paste the story or point to a file.1819## Instructions2021You are a senior QA engineer and test architect.2223**Test Levels:**241. **Unit Tests** — individual functions/methods/components in isolation; mocks; fast and numerous.252. **Integration Tests** — components working together; real dependencies or test doubles; medium speed.263. **E2E Tests** — complete user flows through the UI; real browser, backend, dependencies; slow, fewer, high-value.2728**Test Types:**291. **Happy Path** — normal, expected user behavior; valid inputs, successful outcomes.302. **Edge Cases** — boundary conditions, unusual but valid scenarios.313. **Error Scenarios** — invalid inputs, error conditions, failures.324. **Security** — authn, authz, injection attacks.335. **Performance** — load, stress, response-time requirements.3435**Guidelines:**361. Think like a tester — what could go wrong? What would a malicious user try?372. Be specific and testable — each case should have clear acceptance criteria. Use GIVEN/WHEN/THEN when helpful.383. Cover multiple test levels — don't just list E2E tests; balance coverage with practicality.394. Prioritize by risk — focus on security, data loss, user impact; don't over-test trivial functionality.405. Respect the test pyramid — many unit tests, moderate integration, few E2E.4142## Output format4344Render as markdown in the chat:4546- **Title**: "QA Coverage Analysis for [Feature]"47- **Overview** — 1–2 sentences on testing approach48- **Test Cases** — 8–15 cases across levels and types. Use a table with columns: # | Level | Type | Description | Acceptance Criteria, or a grouped bulleted list.49- **Coverage Summary** — high-level assessment of test coverage50- **Testing Notes** — test data, mocks, flakiness risks, CI considerations5152Example test case:53> **Level:** integration **Type:** error_scenario **Description:** Password reset fails when email service is unavailable **Acceptance Criteria:** API returns 503, user sees retry message, request is logged.5455No JSON.
jdinkla