---

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.
• HALT on ambiguous AC per quality-engineering-test-plan-authoring scenario expansion: ultra-short AC, no expected behavior, bundled ACs, contradiction. Ask before drafting.

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.
• Param contract per SmartBear API Notes.

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.

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".
• No invented expected result: cite the AC or business rule, or tag ASSUMED and surface it for review.
• No rephrased negatives: N and E scenarios must change a precondition or input, not the wording.
• No generation on ambiguous AC: HALT and ask; a convincing TC must not hide a missing requirement.

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