From qa-zephyr-review
Review Zephyr Scale test cases for completeness, clarity, and platform standards. Supports RP1, RP2, LMX, and UAP platforms. Accepts XML file export or fetches via API.
How this skill is triggered — by the user, by Claude, or both
Slash command
/qa-zephyr-review:qa-zephyr-reviewThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
**Run both of these before Phase 1.**
Run both of these before Phase 1.
Step 1 — Detect the repo:
ls tests/integration/karate/src/test/resources/data/templates/common/ 2>/dev/null
rp2_base_template.json present → RP2 moderp1_base_template.json present → RP1 modeStep 2 — Load QA testing context:
curl -s https://raw.githubusercontent.com/Connected2FiberTeam/cb-qa-claude-plugins/main/context/qa-testing-context.md
Once loaded, use only the sections relevant to the detected repo mode (RP1-Specific or RP2-Specific reference sections, platform-appropriate supplier naming, speed formats, instance IDs). Ignore sections for the other platform.
Review Zephyr Scale test cases to ensure they meet quality standards for:
For API Access (Optional):
Zephyr Scale API token enables fetching test cases directly. Check for:
echo $ZEPHYR_SCALE_TOKEN
If not set and you want API access:
~/.zshrc: export ZEPHYR_SCALE_TOKEN="your-token-here"For XML Import (No API Required):
Export test cases from Zephyr Scale as XML and provide the file path.
Ask the user using AskUserQuestion:
Question 1 (header: "Input Method")
Ask for the path to the XML file. The file can be:
$HOME/Downloads/testcase-export.xml)How to export from Zephyr Scale:
Ask for the test case key (e.g., ACE-T1234).
Ask for comma-separated keys (e.g., ACE-T1234, ACE-T1235, ACE-T1236).
Ask for the folder name or test cycle key.
Read the XML file using the Read tool and parse the Zephyr Scale XML structure.
Zephyr Scale XML Structure:
<?xml version="1.0" encoding="UTF-8"?>
<testCases>
<testCase>
<key>ACE-T1234</key>
<name>Test Case Title</name>
<objective>Test objective/description</objective>
<precondition>Prerequisites and setup</precondition>
<status>Draft|Approved|Deprecated</status>
<priority>High|Medium|Low</priority>
<folder>/Folder/Path</folder>
<labels>
<label>label1</label>
</labels>
<testScript>
<steps>
<step>
<index>1</index>
<description>Step description</description>
<testData>Test data for this step</testData>
<expectedResult>Expected outcome</expectedResult>
</step>
</steps>
</testScript>
</testCase>
</testCases>
Note: Zephyr Scale XML exports may vary slightly. Look for these common element names:
testCase, test-case, or TestCasetestSteps, test-steps, steps, or testScriptexpectedResult, expected-result, or expectedOutcomeAPI Base URL: https://api.zephyrscale.smartbear.com/v2
# Fetch single test case
curl -s -H "Authorization: Bearer $ZEPHYR_SCALE_TOKEN" \
"https://api.zephyrscale.smartbear.com/v2/testcases/{testCaseKey}" | jq '.'
# Search test cases by folder
curl -s -H "Authorization: Bearer $ZEPHYR_SCALE_TOKEN" \
"https://api.zephyrscale.smartbear.com/v2/testcases?projectKey=ACE&folderId={folderId}" | jq '.'
# Fetch test steps
curl -s -H "Authorization: Bearer $ZEPHYR_SCALE_TOKEN" \
"https://api.zephyrscale.smartbear.com/v2/testcases/{testCaseKey}/teststeps" | jq '.'
Avoid being overly pedantic. The goal is to identify issues that genuinely impact test usability, not to nitpick formatting or grammar.
Environment listing = environment-agnostic: When a test lists multiple environments (e.g., "Stage/UAT/Prod"), this means the test is designed to run on ANY of those environments. This is the standard practice — do NOT flag as ambiguous.
Intent over perfection in expected results: If the intent of an expected result is clear, do NOT flag minor grammar or wording issues as critical. Only flag if the expected result is genuinely unclear or unverifiable.
Ticket reference provides context: When a title includes a ticket reference like "[ACE-XXXX] Description", the Jira ticket provides the business context. Do NOT require a separate objective field in these cases.
Don't require obvious operational details: Preconditions should document what's non-obvious. Do NOT require DB host URLs when environment is specified, VPN details beyond "VPN required", or standard tool access that any tester would have.
Critical issues = genuinely blocking: Only mark something as "Critical" if it makes the test unusable or unreliable. Grammar issues, missing optional fields, and formatting problems are NOT critical.
RP1 — RemotePricing 1 (legacy)RP2 — RemotePricing 2 (includes LMX/DTAG adapters)LMX — LMX platform (separate legacy platform)UAP — Unified API PlatformNote on Environment:
Note on "Call to Test" Steps:
.claude/qa-testing-context.md (CTTs section)Title: {test_case_title} Status: {current_status} Folder: {folder_path}
| Category | Score | Issues |
|---|---|---|
| Identification | {0-2} | {issues or "None"} |
| Preconditions | {0-2} | {issues or "None"} |
| Test Data | {0-2} | {issues or "None"} |
| Test Steps | {0-2} | {issues or "None"} |
| Expected Results | {0-2} | {issues or "None"} |
Scoring Notes:
[List issues that make the test case unusable or unreliable]
[List issues that reduce test quality but don't block execution]
[Optional enhancements to improve the test case]
Provide specific, actionable recommendations:
1. [Specific change with before/after example]
2. [Specific change with before/after example]
Provider Coverage:
Test Data Completeness:
Automation Readiness:
If reviewing multiple test cases, provide a summary table:
| Test Case | Score | Critical Issues | Status |
|---|---|---|---|
| ACE-T1234 | 8/10 | 0 | Ready |
| ACE-T1235 | 5/10 | 2 | Needs Work |
Overall Assessment:
Question (header: "Next Steps")
Create a markdown file with the review results:
ZEPHYR-REVIEW-{date}-{test_case_key}.md
See .claude/qa-testing-context.md (Test Data Reference section) for the authoritative list of valid platform labels, speed formats, products, access mediums, and address field requirements.
$ARGUMENTS
Provides a checklist for code reviews covering functionality, security, performance, maintainability, tests, and quality. Use for pull requests, audits, team standards, and developer training.
npx claudepluginhub connected2fiberteam/cb-qa-claude-plugins --plugin qa-zephyr-review