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:

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.