--- name: generate-test-plan description: 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. --- ## Name openshift-developer:generate-test-plan ## Synopsis ```text /openshift-developer:generate-test-plan [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 1. 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 2. **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.) - **Project key** (e.g. `OCPSTRAT`, `OCPBUGS`, `CNTRLPLANE`) 3. **OCPSTRAT feature routing**: If the issue's project is `OCPSTRAT` and the issue type is `Feature`, read [references/ocpstrat-feature.md](references/ocpstrat-feature.md) and follow its instructions for template parsing, analysis, scenario generation, document structure, and reporting in all subsequent steps. For **non-OCPSTRAT issues** (or OCPSTRAT issues that do not follow the feature template), do not read the reference — continue with the generic flow below. 4. **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: ```bash gh pr view --repo --json title,body,commits,files,labels,state ``` - Read changed files and their diffs to understand implementation ### Step 2: Analyze changes 1. Identify the type of change (feature, bug fix, refactor) 2. Determine affected components (API, CLI, operator, control-plane, etc.) 3. Find platform-specific changes (AWS, Azure, KubeVirt, etc.) 4. When multiple PRs exist: - Map which PR addresses which component or aspect - Identify dependencies between PRs - Determine testing order 5. Use Grep and Glob to find related test files, configuration, and documentation ### Step 3: Generate test scenarios 1. Map Jira acceptance criteria to test cases (when Jira context available) 2. For bugs: derive test cases from reproduction steps 3. 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 4. 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 1. **From a Jira issue (auto-discovers PRs)**: ```text /openshift-developer:generate-test-plan CNTRLPLANE-205 ``` 2. **From a Jira issue with specific PRs only**: ```text /openshift-developer:generate-test-plan CNTRLPLANE-205 https://github.com/openshift/hypershift/pull/6888 ``` 3. **From PR URLs only (no Jira)**: ```text /openshift-developer:generate-test-plan https://github.com/openshift/hypershift/pull/6888 ``` 4. **Multiple PRs without Jira**: ```text /openshift-developer:generate-test-plan https://github.com/openshift/hypershift/pull/6888 https://github.com/openshift/hypershift/pull/6889 ``` 5. **From an OCPSTRAT feature (generates IEEE 829-style plan with deployment matrix, interop, NFR sections)**: ```text /openshift-developer:generate-test-plan OCPSTRAT-3266 ``` ## 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