# Test Jira Cases

> Generate reviewer-ready, traceable test cases from Jira issues using an available Jira MCP server.

- Skill: `nearform/test-jira-cases` (Agent Skill)
- Install (CLI): `npx skillmds@latest add nearform/test-jira-cases`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nearform/test-jira-cases/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: nearform (https://skillmd.com/u/nearform)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nearform/test-jira-cases

---


# Test Jira Cases

Generate comprehensive, risk-based, reviewer-ready test cases from Jira issues.

Invoke only when the user explicitly requests:

- Test cases
- QA coverage
- Validation scenarios

Do not invoke for:

- Test automation implementation
- Code refactoring
- Jira summarisation without testing intent

## Prerequisites

An MCP server providing Jira issue access is available.

If multiple Jira MCP servers are available, use the most appropriate one.

## Input

Accept:

- Jira key
- Jira URL
- Story
- Bug
- Task
- Subtask
- Epic

Optional:

- Scope focus (API, UI, permissions, reporting, etc.)
- Risk focus (security, payments, performance, accessibility, etc.)
- Maximum number of test cases

If no ticket reference is provided, ask for one.

## Process

1. Retrieve the Jira issue using an available Jira MCP tool.
2. Use available issue information, including:
   - Summary
   - Description
   - Acceptance Criteria
   - Comments
   - Labels
   - Components
   - Status
   - Priority
   - Linked issues
   - Subtasks
   - Relevant custom fields
3. Review linked issues or subtasks only when they materially affect testing scope.
4. Identify:
   - Functional behaviour
   - Business rules
   - User workflows
   - Validation rules
   - State transitions
   - Roles and permissions
   - Integrations and dependencies
   - Error handling
   - Security considerations
   - Boundary and edge cases
   - Business risks
5. If acceptance criteria are missing:
   - Derive explicit numbered requirements from the available information.
   - Label them as **Derived Requirements**.
   - Reduce confidence accordingly.
6. Generate concise, executable, risk-prioritised test cases covering, where applicable:
   - Happy path
   - Negative
   - Boundary
   - Edge case
   - Validation
   - Permission
   - Integration
   - Error recovery
   - Regression
7. Merge duplicate coverage and ensure each test validates one primary behaviour.

If the issue cannot be retrieved:

- Ask the user to provide the ticket contents.
- Continue using only user-provided information.
- Mark confidence as reduced.

If requirements are incomplete or ambiguous:

- Identify gaps.
- Clearly distinguish facts from assumptions.
- Ask clarifying questions when necessary.
- Never invent requirements.

## Validation

Before presenting results, ensure:

- Every acceptance criterion or derived requirement is covered.
- Major workflows are represented.
- Appropriate negative and edge-case testing is included.
- Each test case maps to at least one requirement.
- Steps are concise and executable.
- Expected results are observable.
- Assumptions and gaps are explicit.
- Any uncovered requirement is listed.

## Output

### Coverage Summary

Include:

- Acceptance criteria count
- Derived requirement count
- Test case count
- Coverage areas
- Key risks
- Confidence

Confidence:

- High — Requirements are complete and testable.
- Medium — Minor assumptions required.
- Low — Significant ambiguity or missing information.

### Traceability Matrix

| Requirement / AC | Test Cases |
| ---------------- | ---------- |
| AC-1             | TC-001     |

### Test Cases

For each test case include:

- ID
- Title
- Coverage Area
- Priority (P0–P3)
- Type
- Preconditions
- Steps
- Expected Result
- Traceability
- Notes / Assumptions

Formatting:

- Sequential IDs (TC-001, TC-002...)
- Numbered steps
- Concise reviewer-friendly language
- Observable expected results

### Completion

Include:

- Coverage Summary
- Open Questions
- Risks & Gaps
- Uncovered Requirements (if any)
- Reviewer Recommendation

Reviewer Recommendation:

- Ready for review
- Ready for review with assumptions
- Clarification required before review
- Insufficient requirements for reliable test generation

## Guardrails

- Never invent acceptance criteria, business rules or requirements.
- Clearly separate facts from assumptions.
- Prefer clarification over speculation.
- Never claim complete coverage when requirements are incomplete.
- Use linked issues only when relevant to testing scope.
- Do not expose internal reasoning.