quality-engineering-zephyr-test-generation

# 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 is authoritative for platform colors:
     `#00B8D9` = Web · `#36B37E` = Mobile · `#FF991F` = Web+Mobile
   - See [Actor/Permission Matrix](../quality-engineering-business-analysis/references/analysis_patterns.md) for role/market logic.

2. **Impact Analysis** (run before any TC creation)
   - **Step A — Direct Lookup**: Call `Get Issue Link Test Cases` with the Jira issue key (e.g., `EZRX-42302`).
   - **Step B — Supplemental**: If Step A is 0, search by `[Module]` and `[Screen]` keywords + check sibling issue links.
   - See [Discovery Protocol](references/impact_analysis.md) for full chain.
   - Map each AC to coverage status:
     - **Covered** → ask user: skip or update to current format?
     - **Partial** → always propose a NEW TC.
     - **Not Covered** → always create a NEW TC.

3. **Draft Artifact**:
   - Delete any existing `zephyr_test_plan.md` before writing.
   - Follow the 4-section format in [TC Format Reference](references/tc_format.md) exactly.
   - After writing: read back the file and print full content in the chat so the user can review without opening it.
   - Ask for: review approval, handling of Covered ACs, and the 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 the exact Folder ID provided by the user or specified in Technical Impact.

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

- **`Create Test Case`** requires `projectKey="EZRX"` 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 the key string).
- **`Get Issue Link Test Cases`** uses `issueKey` (e.g., `EZRX-42302`) — 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 the artifact draft; omit prefix only when Platform = "Web and Mobile".
- **No Draft skip**: Always set status = Draft; never auto-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 A 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 the Zephyr TC whenever matching code changes.
- **No vague steps**: Use specific observable outcomes — e.g., `"System works"` → `"Banner 'Success' is visible"`.