# Test Case Design

> Design comprehensive, automation-ready test cases from a Jira story, user story, acceptance criteria, or feature description, in the team's Qase import format. Always use this skill whenever asked to write test cases, design test scenarios, prepare test coverage, or figure out what QA should check for a story or feature — even if the user doesn't say "test case" explicitly (e.g. "what should I test for this story", "get me ready to test this feature", "create TCs for JIRA-482", "give me minimal test cases for this"). Also use it when the user pastes a user story or acceptance criteria and asks what to do with it.

- Skill: `santoshhundekar-qa/test-case-design` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add santoshhundekar-qa/test-case-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/santoshhundekar-qa/test-case-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: santoshhundekar-qa (https://skillmd.com/u/santoshhundekar-qa)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/santoshhundekar-qa/test-case-design

---


# Test Case Design

Turns a Jira story or feature spec into a complete, automation-ready set of test cases in the team's standard import format. Encodes coverage rules learned from real sprint work — not just generic QA theory — so output quality doesn't depend on who's running it or how rushed the sprint is.

## Workflow

When a Jira ID is provided:
1. Fetch and analyze the story, description, acceptance criteria (AC), attachments, and comments.
2. If the story references other stories (linked Jira IDs), fetch those too — but **read them for context and workflow understanding only**. Do NOT write test cases against a referenced story's ACs. Test cases must stay scoped strictly to the target story's own acceptance criteria; each story's test cases live in their own Qase suite.
3. Understand the business flow: validations, permissions, integrations, edge conditions.
4. Ask clarifying questions only if something critical is missing — don't invent acceptance criteria.
5. Generate complete test cases.

If no Jira ID is available, work from whatever story/AC text the user pastes, following the same rules.

**Interdependent story rule of thumb:**
| Use a referenced story to... | Do |
|---|---|
| Understand the full workflow sequence | ✅ |
| Understand what triggers a status change | ✅ |
| Understand what another module expects | ✅ |
| Write TCs for the referenced story's ACs here | ❌ |
| Expand scope beyond the target story's ACs | ❌ |

## Platform detection

Identify the platform from the story summary/description before writing test cases — look for keywords like "Mobile App", "iOS", "Android", "Web Portal", "Admin Portal" (customize this keyword list per project in `references/test-case-template.md`).

- **Mobile (native app)** → tags = `can be automated` (via Appium/Detox)
- **Web (browser-based)** → tags = `can be automated` (via Playwright)

Design steps deterministically so they convert cleanly to the relevant automation framework. See `references/mobile-rules.md` for everything specific to mobile stories — read it whenever the story is a mobile story, don't guess at mobile behavior from web conventions.

## Coverage categories

Cover, where applicable: Positive (Smoke/Functional), Negative, Edge/Boundary, Validation, UI/UX, Security/RBAC, State transition, Error handling, API/integration, and — for mobile stories only — loader/spinner scenarios (never call it "pagination" on mobile). Don't miss lifecycle/end-to-end flows.

Apply standard test design techniques as you go — see `references/design-techniques.md` for definitions, trigger conditions, and worked examples of each. Don't apply all of them to every story; apply whichever technique's trigger condition matches what you're looking at (e.g. a field with a stated limit calls for Boundary Value Analysis, a status field calls for State Transition Testing).

## Minimum required TC set — never drop these, even in minimal mode

No matter how small the story, always include:
- At least 1 **Smoke** TC (standalone, not combinable)
- At least 1 **Negative TC for API/network failure** per save/submit action — expected result must confirm: error shown, data state unchanged, no partial save/ghost record, user stays on screen
- At least 1 TC per distinct **conditional display rule** (field appears for condition A, hides for condition B)
- At least 1 **persistence** TC (value still correct after refresh/re-open/re-login)
- At least 1 **E2E** TC covering the full workflow (standalone, not combinable)
- At least 1 **RBAC** TC per role with access to the feature

## Scenario minimization (only when the user asks for "minimal" test cases)

Combine related sub-scenarios into one TC with numbered sub-steps instead of one TC per case:
- Equivalent category/option values → one TC, N sub-steps
- Multiple missing-field validations → one Negative TC, N sub-steps
- Multiple valid/invalid value combinations → one Edge TC, N sub-steps

Never combine away anything in the "minimum required TC set" above — minimization reduces count, not coverage. Every acceptance criteria line must still map to at least one TC.

## Reusable patterns — apply automatically when the trigger condition is present

See `references/recurring-patterns.md` for the full detail and examples of each:
1. Smoke titles use `[SMOKE]` prefix, not a sequence number; max 4–6 Smoke TCs per story
2. A list with mixed statuses → one TC verifying a change on one card doesn't affect sibling cards
3. Every save/submit action → one API-failure negative TC (see minimum set above)
4. Every save action → a persistence TC across refresh, navigation, and re-login
5. Every conditional field → three TCs: appears on condition met, clears on condition change, retained when unrelated fields change
6. Mutually exclusive actions → TCs proving each side's visibility and one TC proving they never appear together

## Output format

10 lowercase columns, in this order:
```
id | title | description | preconditions | steps_actions | steps_result | type | priority | severity | tags
```
- **Title**: type prefix, not a sequence number — e.g. `[SMOKE] | Filter icon opens bottom sheet on Active tab`, `[Negative] | Submit API failure keeps record in prior state and shows error message`
- **Type**: Smoke / Functional / Negative / Edge / Security / UI / Performance / E2E
- **Tags**: `can be automated` only (mobile → Appium/Detox, web → Playwright) — no other labels, and no separate automation column
- **Steps**: numbered, steps_actions and steps_result 1-to-1 aligned

See `references/test-case-template.md` for the exact column template and your project's platform reference (modules, statuses, ID format, RBAC roles — fill in per project).

Before finalizing, run through `references/coverage-checklist.md`.

## Delivering as a Qase-importable file

After the test cases are finalized (not before — don't build the file while still iterating on content), also produce an actual `.xlsx` file, not just the table shown in chat, so it can be imported into Qase or opened directly in Excel:

1. Consult the xlsx skill for how to build the workbook correctly in this environment (openpyxl usage, gotchas, recalc step) — don't hand-roll spreadsheet creation.
2. Row 1 = the 10 lowercase headers in the exact order from `references/test-case-template.md`; one test case per row below it.
3. Apply the Excel color-coding table from `references/test-case-template.md` as a fill color on each row based on its `type` value (e.g. Smoke rows filled gold/yellow, Negative rows filled orange).
4. Save the file and present it to the user as a downloadable file — don't just describe that a file "could" be made.
5. If the user only asked to see test cases in chat and didn't ask for a file, still offer the `.xlsx` at the end rather than producing it unprompted every time — some review passes are chat-only until the content is finalized.

## What not to do
- Don't invent acceptance criteria or UI details not in the story or linked design — flag gaps instead of guessing.
- Don't write test cases against a linked/interdependent story's own ACs.
- Don't drop anything from the minimum required TC set, even in minimal mode.
- Don't apply desktop-only assumptions (hover, keyboard shortcuts, pagination, right-click) to mobile stories — check `references/mobile-rules.md` first.