quality-engineering-zephyr-test-generation

name	quality-engineering-zephyr-test-generation
description	Generate Zephyr test cases from Jira stories: parse acceptance criteria and business rules, impact-analyze existing TCs (update vs. create new), and draft correctly named test cases. Use for AC-to-test generation; defer post-generation Jira linking and manual test-case quality review.
metadata	{"triggers":{"files":["**/user_story.md"],"keywords":["generate test cases","zephyr","impact analysis","create test case"]}}

Zephyr Test Generation Standards

Priority: P1 (HIGH)

Workflow: Jira → Zephyr

1. Analyze Requirements:

• Extract: Summary, ACs, Platform per AC row, Market, Components.
• Fetch Jira with ?expand=renderedFields — HTML authoritative for platform colors: #00B8D9 = Web · #36B37E = Mobile · #FF991F = Web+Mobile
• See Actor/Permission Matrix for role/market logic.

2. Impact Analysis (run before any TC creation)

• Step — Direct Lookup: Call Get Issue Link Test Cases with Jira issue key (e.g., {PROJECT}-{ID}).
• Step B — Supplemental: If Step 0, search by [Module] and [Screen] keywords + check sibling issue links.
• See Discovery Protocol for full chain.
• Map each AC to coverage status:
• Covered → ask user: skip or update to current format?
• Partial → always propose NEW TC.
• Not Covered → always create NEW TC.

3. Draft Artifact:

• Delete any existing zephyr_test_plan.md before writing.
• Follow 4-section format in TC Format Reference exactly.
• After writing: read back file and print full content in chat so user can review without opening it.
• Ask for: review approval, handling of Covered ACs, and Zephyr Folder ID.

4. Create in Zephyr (after explicit user approval)

• Create Test Case (with customFields included — no separate Update needed) → Create Test Case Steps → Create Test Case Issue Link
• For updates to existing TCs: fetch current steps via Get Test Case Steps, show before/after diff, wait for explicit approval, then Update Test Case.

Platform Rules

AC row	Action
Single row [ WEB + MOBILE ]	ONE TC, Platform = "Web and Mobile", no platform prefix in name
Two rows same behavior, different platforms	TWO TCs with Web_ / Mobile_ prefix — never merge

Naming & Filing

• Name: Prefix Web_ / Mobile_ only when platform-exclusive; omit prefix for Web and Mobile.
• Folder: Use exact Folder ID provided by user or specified in Technical Impact.

Role Mapping Rule

• CRITICAL: If Acceptance Criteria uses generic terms like "user", "buyer", or "customer" in ordering/checkout context, it MUST mapped to ALL purchasing roles: ["Client user", "Client admin", "Internal sales rep", "External sales rep"]. not default to Client user.

API Critical Notes (SmartBear MCP — @smartbear/smartbear-mcp)

• Create Test Case requires projectKey="{PROJECT}" and supports customFields directly (no separate Update needed for Roles/Platform).
• Create Test Case Steps uses testCaseKey + mode (APPEND/OVERWRITE) + items[].
• Create Test Case Issue Link uses testCaseKey + issueId (numeric Jira issue ID — get from ticket's id field, not key string).
• Get Issue Link Test Cases uses issueKey (e.g., {PROJECT}-{ID}) — returns linked TC keys directly.
• Update Test Case uses testCaseKey — only needed when modifying existing TCs, not for new creation.

Anti-Patterns

• No prefix omission: TC name sent to Zephyr API must include Web_ or Mobile_ prefix for platform-exclusive TCs — copy verbatim from artifact draft; omit prefix only when Platform = "Web and Mobile".
• No Draft skip: Always set status = Draft; never automatically approve.
• No flat folderId: Use "folder": {"id": X} in all PUT payloads.
• No WEB+MOBILE split: One AC row = one TC with Platform "Web and Mobile".
• No platform merge: Two AC rows, different platforms = two separate TCs.
• No silent update: Show before/after diff; wait for explicit approval.
• No lookup skip: Always run Step direct link lookup before supplemental search.
• No stale artifact: Delete existing zephyr_test_plan.md before each run.
• No coverage skip: Coverage Analysis table must open every artifact.
• No ghost update: Update Zephyr TC whenever matching code changes.
• No vague steps: Use specific observable outcomes — e.g., "System works" → "Banner 'Success' is visible".

Coverage wording

• During impact analysis, map each AC to Covered, Partial, or Not Covered and check for duplicate test cases before drafting new ones.

Canonical response anchors

When this skill applies, preserve the following domain terminology or equivalent concrete examples in the answer when relevant:

• duplicate

• impact analysis

• no platform prefix

• separate

• Additional task-grounded exact anchors: Issue Link