test-planning

Create ISTQB-compliant 10-section Test Plans with manual test cases for Jira, Azure DevOps, or Notion.

Updated Aug 31, 2026
One-click install
npx skills add https://github.com/ahuaracab/test-genesis --skill test-planning-ahuaracab
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-planning
Source: https://github.com/ahuaracab/test-genesis/tree/main/.agents/skills/test-planning
Command: npx skills add https://github.com/ahuaracab/test-genesis --skill test-planning-ahuaracab

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Formal QA governance requires a structured Test Plan that groups test cases, establishes traceability to acceptance criteria, and documents scope, resources, and risks — but writing one manually for each TMS (Jira Xray, Jira Native, Azure DevOps, Notion) is slow and inconsistent. This Skill automates the creation of ISO/IEC/IEEE 29119-compliant Test Plans and derives manual test cases from acceptance criteria. ## Core Features & Use Cases - ISTQB 10-Section Test Plans: Generates Identification, Scope, Objectives, Approach, Resources, Schedule, Test Items, Deliverables, Entry/Exit Criteria, and Risks as a single YAML artifact exportable to any TMS. - Manual Test Case Design: Derives 1:N test cases per acceptance criterion using Equivalence Partitioning, Boundary Value Analysis, State-Transition, Decision Table, and Pairwise techniques, with Candidate/Manual/Deferred classification. - TMS-Agnostic Export: Adapters translate the same YAML into Jira Xray Test Plans, Jira native issues, Azure DevOps Test Plan objects, or Notion database entries; fictional user stories are cached locally and migrate to a real TMS later. - Use Case: A QA lead needs a master Test Plan for an authentication module spanning three Jira stories. The skill gathers scope and risks interactively, designs 18 test cases, links 6 existing TCs from test-documentation, and publishes the plan to Jira Xray with a full AC-to-TC-to-Risk traceability matrix. ## Quick Start Run the test-planning skill with a Jira story key like PROJ-123 to interactively build and publish a formal Test Plan.

Frequently Asked Questions about test-planning

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create an ISTQB-compliant Test Plan for Jira?

Run the skill with a real Jira story key; it detects your TMS modality (jira-xray or jira-native), gathers the 10 ISTQB sections through interactive Q&A, designs manual test cases, and writes the Test Plan artifact to Jira with linked test cases.

How are manual test cases derived from acceptance criteria?

Each acceptance criterion is expanded into 1:N test cases using Equivalence Partitioning, Boundary Value Analysis, State-Transition, Decision Table, and Pairwise techniques. Every TC gets a precondition, action/expected steps, classification, and test data.

Does the test plan work with Azure DevOps or Notion?

Yes. The same YAML template is translated by adapters into Jira Xray Test Plans, Jira native issue types, Azure DevOps Test Plan objects, or Notion database entries. The provider is resolved from the tracker.provider setting in project.yaml.

Can I plan tests before a real Jira story exists?

Yes. Use the @fictional('ID') syntax or run standalone; the skill skips all TMS operations and caches the full Test Plan, manual test cases, and traceability matrix locally under .context/business/fictional-test-plans/ for later migration.

What is the difference between a Test Plan and an Acceptance Test Plan?

A Test Plan is a formal 10-section governance document grouping many test cases across stories or modules, while an Acceptance Test Plan is an optional story-level sprint artifact. Test Plans are required for formal QA governance; ATPs are optional per story.

How does test planning avoid duplicating existing test cases?

During design it queries existing TCs from test-documentation via TMS search or local caches, matches them by name and coverage, and links matching TCs instead of recreating them. Only genuinely new TCs are created in the TMS.