Name
openshift-developer:generate-test-plan
Synopsis
/openshift-developer:generate-test-plan <JIRA_KEY | PR_URL> [additional PR URLs...]
Description
Generates a comprehensive manual testing guide by analyzing a Jira issue, one or more GitHub PRs, or both. Consolidates context from Jira acceptance criteria, PR diffs, commit messages, and changed files into actionable test scenarios.
When given a Jira key, it auto-discovers linked PRs. When given PR URLs directly, it works without Jira. Both can be combined.
Implementation
Step 1: Parse input and gather sources
Parse arguments:
- If
$1 matches a Jira issue key pattern (e.g. CNTRLPLANE-205, OCPBUGS-12345): treat as Jira key
- If
$1 is a GitHub URL: treat as PR URL (no Jira context)
- Remaining arguments (
$2, $3, ...): additional PR URLs
If a Jira key was provided, fetch Jira issue details using the Jira MCP tools (mcp__atlassian__jira_get_issue):
- Issue summary, description, acceptance criteria
- Steps to reproduce (for bugs)
- Issue type (Story, Bug, Task, etc.)
Discover PRs:
- If explicit PR URLs were provided: use only those
- If only a Jira key was provided: use
mcp__atlassian__jira_get_issue with include: "remote_links" and look for GitHub PR links. Also check the issue description and comments for PR URLs.
- For each PR, fetch details:
gh pr view <PR_NUMBER> --repo <owner/repo> --json title,body,commits,files,labels,state
- Read changed files and their diffs to understand implementation
Step 2: Analyze changes
- Identify the type of change (feature, bug fix, refactor)
- Determine affected components (API, CLI, operator, control-plane, etc.)
- Find platform-specific changes (AWS, Azure, KubeVirt, etc.)
- When multiple PRs exist:
- Map which PR addresses which component or aspect
- Identify dependencies between PRs
- Determine testing order
- Use Grep and Glob to find related test files, configuration, and documentation
Step 3: Generate test scenarios
- Map Jira acceptance criteria to test cases (when Jira context available)
- For bugs: derive test cases from reproduction steps
- Generate scenarios covering:
- Happy path (based on acceptance criteria or PR description)
- Edge cases and error handling
- Platform-specific variations if applicable
- Regression scenarios for related features
- For multiple PRs: create integration scenarios verifying PRs work together
Step 4: Apply smart filtering
Skip PRs that don't require testing:
- PRs with only documentation changes (
.md files)
- PRs with only CI/tooling changes (
.github/, .claude/ directories)
- PRs with labels like
skip-testing or docs-only
Note skipped PRs in the output with reasoning.
Step 5: Create the test guide
Filename convention:
- Jira-based:
test-{jira-key-lowercase}.md (e.g. test-cntrlplane-205.md)
- PR-only:
test-pr-{number1}-{number2}.md (e.g. test-pr-6888-6889.md)
Document structure:
- Summary: Jira key + title (if available), list of PRs with titles, overall objective
- Prerequisites: Required infrastructure, tools, environment setup, access requirements
- Test Scenarios: Numbered test cases with:
- Clear step-by-step instructions
- Expected results and verification commands
- Mapping to acceptance criteria (when Jira context available)
- Platform-specific variations where applicable
- Regression Testing: Related features to verify, areas that might be affected
- Success Criteria: Checklist mapping to Jira acceptance criteria (when available)
- Troubleshooting: Common issues and debug steps
- Notes: Known limitations, links to Jira and PRs, dependencies between PRs
Exclusions: Do NOT include build/deploy steps or cleanup steps. Assume the environment is already set up. Focus purely on testing procedures.
Step 6: Report
- Show the file path where the guide was saved
- Summarize: Jira issue (if applicable), number of PRs analyzed, number of test scenarios, critical test cases
- Highlight skipped PRs and reasoning
- Ask if the user wants modifications
Examples
From a Jira issue (auto-discovers PRs):
/openshift-developer:generate-test-plan CNTRLPLANE-205
From a Jira issue with specific PRs only:
/openshift-developer:generate-test-plan CNTRLPLANE-205 https://github.com/openshift/hypershift/pull/6888
From PR URLs only (no Jira):
/openshift-developer:generate-test-plan https://github.com/openshift/hypershift/pull/6888
Multiple PRs without Jira:
/openshift-developer:generate-test-plan https://github.com/openshift/hypershift/pull/6888 https://github.com/openshift/hypershift/pull/6889
Arguments
$1 — Jira issue key (e.g. CNTRLPLANE-205) or a GitHub PR URL (required)
$2, $3, ..., $N — Additional GitHub PR URLs (optional)
Guidelines
- Use Jira MCP tools for Jira data,
gh CLI for PR data
- Derive test scenarios from actual code changes, not assumptions
- Keep test steps concrete with exact commands and expected output
- When Jira acceptance criteria exist, map every criterion to at least one test case
1---2name: generate-test-plan3description: Generate a comprehensive manual testing guide from a Jira issue, GitHub PR URLs, or both. Use when the user wants test steps, a QE test plan, or a testing guide for code changes.4---56## Name7openshift-developer:generate-test-plan89## Synopsis10```text11/openshift-developer:generate-test-plan <JIRA_KEY | PR_URL> [additional PR URLs...]12```1314## Description15Generates a comprehensive manual testing guide by analyzing a Jira issue, one or more GitHub PRs, or both. Consolidates context from Jira acceptance criteria, PR diffs, commit messages, and changed files into actionable test scenarios.1617When given a Jira key, it auto-discovers linked PRs. When given PR URLs directly, it works without Jira. Both can be combined.1819## Implementation2021### Step 1: Parse input and gather sources22231. Parse arguments:24 - If `$1` matches a Jira issue key pattern (e.g. `CNTRLPLANE-205`, `OCPBUGS-12345`): treat as Jira key25 - If `$1` is a GitHub URL: treat as PR URL (no Jira context)26 - Remaining arguments (`$2`, `$3`, ...): additional PR URLs27282. **If a Jira key was provided**, fetch Jira issue details using the Jira MCP tools (`mcp__atlassian__jira_get_issue`):29 - Issue summary, description, acceptance criteria30 - Steps to reproduce (for bugs)31 - Issue type (Story, Bug, Task, etc.)32333. **Discover PRs**:34 - If explicit PR URLs were provided: use only those35 - If only a Jira key was provided: use `mcp__atlassian__jira_get_issue` with `include: "remote_links"` and look for GitHub PR links. Also check the issue description and comments for PR URLs.36 - For each PR, fetch details:37 ```bash38 gh pr view <PR_NUMBER> --repo <owner/repo> --json title,body,commits,files,labels,state39 ```40 - Read changed files and their diffs to understand implementation4142### Step 2: Analyze changes43441. Identify the type of change (feature, bug fix, refactor)452. Determine affected components (API, CLI, operator, control-plane, etc.)463. Find platform-specific changes (AWS, Azure, KubeVirt, etc.)474. When multiple PRs exist:48 - Map which PR addresses which component or aspect49 - Identify dependencies between PRs50 - Determine testing order515. Use Grep and Glob to find related test files, configuration, and documentation5253### Step 3: Generate test scenarios54551. Map Jira acceptance criteria to test cases (when Jira context available)562. For bugs: derive test cases from reproduction steps573. Generate scenarios covering:58 - Happy path (based on acceptance criteria or PR description)59 - Edge cases and error handling60 - Platform-specific variations if applicable61 - Regression scenarios for related features624. For multiple PRs: create integration scenarios verifying PRs work together6364### Step 4: Apply smart filtering6566Skip PRs that don't require testing:67- PRs with only documentation changes (`.md` files)68- PRs with only CI/tooling changes (`.github/`, `.claude/` directories)69- PRs with labels like `skip-testing` or `docs-only`7071Note skipped PRs in the output with reasoning.7273### Step 5: Create the test guide7475**Filename convention**:76- Jira-based: `test-{jira-key-lowercase}.md` (e.g. `test-cntrlplane-205.md`)77- PR-only: `test-pr-{number1}-{number2}.md` (e.g. `test-pr-6888-6889.md`)7879**Document structure**:8081- **Summary**: Jira key + title (if available), list of PRs with titles, overall objective82- **Prerequisites**: Required infrastructure, tools, environment setup, access requirements83- **Test Scenarios**: Numbered test cases with:84 - Clear step-by-step instructions85 - Expected results and verification commands86 - Mapping to acceptance criteria (when Jira context available)87 - Platform-specific variations where applicable88- **Regression Testing**: Related features to verify, areas that might be affected89- **Success Criteria**: Checklist mapping to Jira acceptance criteria (when available)90- **Troubleshooting**: Common issues and debug steps91- **Notes**: Known limitations, links to Jira and PRs, dependencies between PRs9293**Exclusions**: Do NOT include build/deploy steps or cleanup steps. Assume the environment is already set up. Focus purely on testing procedures.9495### Step 6: Report9697- Show the file path where the guide was saved98- Summarize: Jira issue (if applicable), number of PRs analyzed, number of test scenarios, critical test cases99- Highlight skipped PRs and reasoning100- Ask if the user wants modifications101102## Examples1031041. **From a Jira issue (auto-discovers PRs)**:105 ```text106 /openshift-developer:generate-test-plan CNTRLPLANE-205107 ```1081092. **From a Jira issue with specific PRs only**:110 ```text111 /openshift-developer:generate-test-plan CNTRLPLANE-205 https://github.com/openshift/hypershift/pull/6888112 ```1131143. **From PR URLs only (no Jira)**:115 ```text116 /openshift-developer:generate-test-plan https://github.com/openshift/hypershift/pull/6888117 ```1181194. **Multiple PRs without Jira**:120 ```text121 /openshift-developer:generate-test-plan https://github.com/openshift/hypershift/pull/6888 https://github.com/openshift/hypershift/pull/6889122 ```123124## Arguments125- `$1` — Jira issue key (e.g. `CNTRLPLANE-205`) or a GitHub PR URL (required)126- `$2, $3, ..., $N` — Additional GitHub PR URLs (optional)127128## Guidelines129- Use Jira MCP tools for Jira data, `gh` CLI for PR data130- Derive test scenarios from actual code changes, not assumptions131- Keep test steps concrete with exact commands and expected output132- When Jira acceptance criteria exist, map every criterion to at least one test case