MCPInstall

qa-test-planner

Generate comprehensive test plans, manual test cases, regression test suites, and bug reports for QA engineers. Includes Figma MCP integration for design validation.

Installs
4.3K
Last 24h
—
Trending rank
—
Security
Warn

Install

Works with every agent the skills CLI supports.

npx skills add https://github.com/softaworks/agent-toolkit --skill qa-test-planner
  1. 01

    Install

    Run the command in your project. The CLI asks which agents to install for.

  2. 02

    Describe the task

    Ask your agent for something this skill covers. It loads qa-test-planner automatically when relevant.

  3. 03

    Review the result

    The agent follows the SKILL.md steps, scripts and references bundled with the skill.

Security audits

Independent scans of the skill's instructions and bundled files.

Gen Agent Trust Hub WarnMEDIUM ·The skill is generally well-structured for QA documentation tasks but contains an unsafe eval pattern in its companion bash scripts that could allow command injection, along with a typical indirect prompt injection risk from processing untrusted requirements.
Socket Warn2 alerts: gptSecurity
Snyk PassLOW ·Risk: LOW · No issues
Runlayer PassLOW ·1/8 files flagged
ZeroLeaks PassLOW ·1 finding · Score: 86/100

SKILL.md

The instructions your agent reads when the skill is triggered.

QA Test Planner

A comprehensive skill for QA engineers to create test plans, generate manual test cases, build regression test suites, validate designs against Figma, and document bugs effectively.

Activation: This skill is triggered only when explicitly called by name (e.g., /qa-test-planner, qa-test-planner, or use the skill qa-test-planner).


Quick Start

Create a test plan:

"Create a test plan for the user authentication feature"

Generate test cases:

"Generate manual test cases for the checkout flow"

Build regression suite:

"Build a regression test suite for the payment module"

Validate against Figma:

"Compare the login page against the Figma design at [URL]"

Create bug report:

"Create a bug report for the form validation issue"

Quick Reference

TaskWhat You GetTime
Test PlanStrategy, scope, schedule, risks10-15 min
Test CasesStep-by-step instructions, expected results5-10 min each
Regression SuiteSmoke tests, critical paths, execution order15-20 min
Figma ValidationDesign-implementation comparison, discrepancy list10-15 min
Bug ReportReproducible steps, environment, evidence5 min

How It Works

Your Request
    │
    ▼
┌─────────────────────────────────────────────────────┐
│ 1. ANALYZE                                          │
│    • Parse feature/requirement                      │
│    • Identify test types needed                     │
│    • Determine scope and priorities                 │
├─────────────────────────────────────────────────────┤
│ 2. GENERATE                                         │
│    • Create structured deliverables                 │
│    • Apply templates and best practices             │
│    • Include edge cases and variations              │
├─────────────────────────────────────────────────────┤
│ 3. VALIDATE                                         │
│    • Check completeness                             │
│    • Verify traceability                            │
│    • Ensure actionable steps                        │
└─────────────────────────────────────────────────────┘
    │
    ▼
QA Deliverable Ready

Commands

Interactive Scripts

ScriptPurposeUsage
./scripts/generate_test_cases.shCreate test cases interactivelyStep-by-step prompts
./scripts/create_bug_report.shGenerate bug reportsGuided input collection

Natural Language

RequestOutput
"Create test plan for {feature}"Complete test plan document
"Generate {N} test cases for {feature}"Numbered test cases with steps
"Build smoke test suite"Critical path tests
"Compare with Figma at {URL}"Visual validation checklist
"Document bug: {description}"Structured bug report

Core Deliverables

1. Test Plans

  • Test scope and objectives
  • Testing approach and strategy
  • Environment requirements
  • Entry/exit criteria
  • Risk assessment
  • Timeline and milestones

2. Manual Test Cases

  • Step-by-step instructions
  • Expected vs actual results
  • Preconditions and setup
  • Test data requirements
  • Priority and severity

3. Regression Suites

  • Smoke tests (15-30 min)
  • Full regression (2-4 hours)
  • Targeted regression (30-60 min)
  • Execution order and dependencies

4. Figma Validation

  • Component-by-component comparison
  • Spacing and typography checks
  • Color and visual consistency
  • Interactive state validation

5. Bug Reports

  • Clear reproduction steps
  • Environment details
  • Evidence (screenshots, logs)
  • Severity and priority

Anti-Patterns

AvoidWhyInstead
Vague test stepsCan't reproduceSpecific actions + expected results
Missing preconditionsTests fail unexpectedlyDocument all setup requirements
No test dataTester blockedProvide sample data or generation
Generic bug titlesHard to trackSpecific: "[Feature] issue when [action]"
Skip edge casesMiss critical bugsInclude boundary values, nulls

Verification Checklist

Test Plan:

  • Scope clearly defined (in/out)
  • Entry/exit criteria specified
  • Risks identified with mitigations
  • Timeline realistic

Test Cases:

  • Each step has expected result
  • Preconditions documented
  • Test data available
  • Priority assigned

Bug Reports:

  • Reproducible steps
  • Environment documented
  • Screenshots/evidence attached
  • Severity/priority set

References

  • Test Case Templates - Standard formats for all test types
  • Bug Report Templates - Documentation templates
  • Regression Testing Guide - Suite building and execution
  • Figma Validation Guide - Design-implementation validation

<details> <summary><strong>Deep Dive: Test Case Structure</strong></summary>

Standard Test Case Format

## TC-001: [Test Case Title]

**Priority:** High | Medium | Low
**Type:** Functional | UI | Integration | Regression
**Status:** Not Run | Pass | Fail | Blocked

### Objective
[What are we testing and why]

### Preconditions
- [Setup requirement 1]
- [Setup requirement 2]
- [Test data needed]

### Test Steps
1. [Action to perform]
   **Expected:** [What should happen]

2. [Action to perform]
   **Expected:** [What should happen]

3. [Action to perform]
   **Expected:** [What should happen]

### Test Data
- Input: [Test data values]
- User: [Test account details]
- Configuration: [Environment settings]

### Post-conditions
- [System state after test]
- [Cleanup required]

### Notes
- [Edge cases to consider]
- [Related test cases]
- [Known issues]

Test Types

TypeFocusExample
FunctionalBusiness logicLogin with valid credentials
UI/VisualAppearance, layoutButton matches Figma design
IntegrationComponent interactionAPI returns data to frontend
RegressionExisting functionalityPrevious features still work
PerformanceSpeed, load handlingPage loads under 3 seconds
SecurityVulnerabilitiesSQL injection prevented
</details> <details> <summary><strong>Deep Dive: Test Plan Template</strong></summary>

Test Plan Structure

# Test Plan: [Feature/Release Name]

## Executive Summary
- Feature/product being tested
- Testing objectives
- Key risks
- Timeline overview

## Test Scope

**In Scope:**
- Features to be tested
- Test types (functional, UI, performance)
- Platforms and environments
- User flows and scenarios

**Out of Scope:**
- Features not being tested
- Known limitations
- Third-party integrations (if applicable)

## Test Strategy

**Test Types:**
- Manual testing
- Exploratory testing
- Regression testing
- Integration testing
- User acceptance testing

**Test Approach:**
- Black box testing
- Positive and negative testing
- Boundary value analysis
- Equivalence partitioning

## Test Environment
- Operating systems
- Browsers and versions
- Devices (mobile, tablet, desktop)
- Test data requirements
- Backend/API environments

## Entry Criteria
- [ ] Requirements documented
- [ ] Designs finalized
- [ ] Test environment ready
- [ ] Test data prepared
- [ ] Build deployed

## Exit Criteria
- [ ] All high-priority test cases executed
- [ ] 90%+ test case pass rate
- [ ] All critical bugs fixed
- [ ] No open high-severity bugs
- [ ] Regression suite passed

## Risk Assessment

| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| [Risk 1] | H/M/L | H/M/L | [Mitigation] |

## Test Deliverables
- Test plan document
- Test cases
- Test execution reports
- Bug reports
- Test summary report
</details> <details> <summary><strong>Deep Dive: Bug Reporting</strong></summary>

Bug Report Template

# BUG-[ID]: [Clear, specific title]

**Severity:** Critical | High | Medium | Low
**Priority:** P0 | P1 | P2 | P3
**Type:** Functional | UI | Performance | Security
**Status:** Open | In Progress | Fixed | Closed

## Environment
- **OS:** [Windows 11, macOS 14, etc.]
- **Browser:** [Chrome 120, Firefox 121, etc.]
- **Device:** [Desktop, iPhone 15, etc.]
- **Build:** [Version/commit]
- **URL:** [Page where bug occurs]

## Description
[Clear, concise description of the issue]

## Steps to Reproduce
1. [Specific step]
2. [Specific step]
3. [Specific step]

## Expected Behavior
[What should happen]

## Actual Behavior
[What actually happens]

## Visual Evidence
- Screenshot: [attached]
- Video: [link if applicable]
- Console errors: [paste errors]

## Impact
- **User Impact:** [How many users affected]
- **Frequency:** [Always, Sometimes, Rarely]
- **Workaround:** [If one exists]

## Additional Context
- Related to: [Feature/ticket]
- Regression: [Yes/No]
- Figma design: [Link if UI bug]

Severity Definitions

LevelCriteriaExamples
Critical (P0)System crash, data loss, securityPayment fails, login broken
High (P1)Major feature broken, no workaroundSearch not working
Medium (P2)Feature partial, workaround existsFilter missing one option
Low (P3)Cosmetic, rare edge casesTypo, minor alignment
</details> <details> <summary><strong>Deep Dive: Figma MCP Integration</strong></summary>

Design Validation Workflow

Prerequisites:

  • Figma MCP server configured
  • Access to Figma design files
  • Figma URLs for components/pages

Process:

  1. Get Design Specs from Figma
"Get the button specifications from Figma file [URL]"

Response includes:
- Dimensions (width, height)
- Colors (background, text, border)
- Typography (font, size, weight)
- Spacing (padding, margin)
- Border radius
- States (default, hover, active, disabled)
  1. Compare Implementation
TC: Primary Button Visual Validation
1. Inspect primary button in browser dev tools
2. Compare against Figma specs:
   - Dimensions: 120x40px
   - Border-radius: 8px
   - Background color: #0066FF
   - Font: 16px Medium #FFFFFF
3. Document discrepancies
  1. Create Bug if Mismatch
BUG: Primary button color doesn't match design
Severity: Medium
Expected (Figma): #0066FF
Actual (Implementation): #0052CC
Screenshot: [attached]
Figma link: [specific component]

What to Validate

ElementWhat to CheckTool
ColorsHex values exactBrowser color picker
SpacingPadding/margin pxDevTools computed styles
TypographyFont, size, weightDevTools font panel
LayoutWidth, height, positionDevTools box model
StatesHover, active, focusManual interaction
ResponsiveBreakpoint behaviorDevTools device mode

Example Queries

"Get button specifications from Figma design [URL]"
"Compare navigation menu implementation against Figma design"
"Extract spacing values for dashboard layout from Figma"
"List all color tokens used in Figma design system"
</details> <details> <summary><strong>Deep Dive: Regression Testing</strong></summary>

Suite Structure

Suite TypeDurationFrequencyCoverage
Smoke15-30 minDailyCritical paths only
Targeted30-60 minPer changeAffected areas
Full2-4 hoursWeekly/ReleaseComprehensive
Sanity10-15 minAfter hotfixQuick validation

Building a Regression Suite

Step 1: Identify Critical Paths

  • What can users NOT live without?
  • What generates revenue?
  • What handles sensitive data?
  • What's used most frequently?

Step 2: Prioritize Test Cases

PriorityDescriptionMust Run
P0Business-critical, securityAlways
P1Major features, common flowsWeekly+
P2Minor features, edge casesReleases

Step 3: Execution Order

  1. Smoke first - if fails, stop and fix build
  2. P0 tests next - must pass before proceeding
  3. P1 then P2 - track all failures
  4. Exploratory - find unexpected issues

Pass/Fail Criteria

PASS:

  • All P0 tests pass
  • 90%+ P1 tests pass
  • No critical bugs open

FAIL (Block Release):

  • Any P0 test fails
  • Critical bug discovered
  • Security vulnerability
  • Data loss scenario

CONDITIONAL:

  • P1 failures with workarounds
  • Known issues documented
  • Fix plan in place
</details> <details> <summary><strong>Deep Dive: Test Execution Tracking</strong></summary>

Test Run Report Template

# Test Run: [Release Version]

**Date:** 2024-01-15
**Build:** v2.5.0-rc1
**Tester:** [Name]
**Environment:** Staging

## Summary
- Total Test Cases: 150
- Executed: 145
- Passed: 130
- Failed: 10
- Blocked: 5
- Not Run: 5
- Pass Rate: 90%

## Test Cases by Priority

| Priority | Total | Pass | Fail | Blocked |
|----------|-------|------|------|---------|
| P0 (Critical) | 25 | 23 | 2 | 0 |
| P1 (High) | 50 | 45 | 3 | 2 |
| P2 (Medium) | 50 | 45 | 3 | 2 |
| P3 (Low) | 25 | 17 | 2 | 1 |

## Critical Failures
- TC-045: Payment processing fails
  - Bug: BUG-234
  - Status: Open

## Blocked Tests
- TC-112: Dashboard widget (API endpoint down)

## Risks
- 2 critical bugs blocking release
- Payment integration needs attention

## Next Steps
- Retest after BUG-234 fix
- Complete remaining 5 test cases
- Run full regression before sign-off

Coverage Tracking

## Coverage Matrix

| Feature | Requirements | Test Cases | Status | Gaps |
|---------|--------------|------------|--------|------|
| Login | 8 | 12 | Complete | None |
| Checkout | 15 | 10 | Partial | Payment errors |
| Dashboard | 12 | 15 | Complete | None |
</details> <details> <summary><strong>QA Process Workflow</strong></summary>

Phase 1: Planning

  • Review requirements and designs
  • Create test plan
  • Identify test scenarios
  • Estimate effort and timeline
  • Set up test environment

Phase 2: Test Design

  • Write test cases
  • Review test cases with team
  • Prepare test data
  • Build regression suite
  • Get Figma design access

Phase 3: Execution

  • Execute test cases
  • Log bugs with clear steps
  • Validate against Figma (UI tests)
  • Track test progress
  • Communicate blockers

Phase 4: Reporting

  • Compile test results
  • Analyze coverage
  • Document risks
  • Provide go/no-go recommendation
  • Archive test artifacts
</details> <details> <summary><strong>Best Practices</strong></summary>

Test Case Writing

DO:

  • Be specific and unambiguous
  • Include expected results for each step
  • Test one thing per test case
  • Use consistent naming conventions
  • Keep test cases maintainable

DON'T:

  • Assume knowledge
  • Make test cases too long
  • Skip preconditions
  • Forget edge cases
  • Leave expected results vague

Bug Reporting

DO:

  • Provide clear reproduction steps
  • Include screenshots/videos
  • Specify exact environment details
  • Describe impact on users
  • Link to Figma for UI bugs

DON'T:

  • Report without reproduction steps
  • Use vague descriptions
  • Skip environment details
  • Forget to assign priority
  • Duplicate existing bugs

Regression Testing

DO:

  • Automate repetitive tests when possible
  • Maintain regression suite regularly
  • Prioritize critical paths
  • Run smoke tests frequently
  • Update suite after each release

DON'T:

  • Skip regression before releases
  • Let suite become outdated
  • Test everything every time
  • Ignore failed regression tests
</details>

Examples

<details> <summary><strong>Example: Login Flow Test Case</strong></summary>
## TC-LOGIN-001: Valid User Login

**Priority:** P0 (Critical)
**Type:** Functional
**Estimated Time:** 2 minutes

### Objective
Verify users can successfully login with valid credentials

### Preconditions
- User account exists (test@example.com / Test123!)
- User is not already logged in
- Browser cookies cleared

### Test Steps
1. Navigate to https://app.example.com/login
   **Expected:** Login page displays with email and password fields

2. Enter email: test@example.com
   **Expected:** Email field accepts input

3. Enter password: Test123!
   **Expected:** Password field shows masked characters

4. Click "Login" button
   **Expected:**
   - Loading indicator appears
   - User redirected to /dashboard
   - Welcome message shown: "Welcome back, Test User"
   - Avatar/profile image displayed in header

### Post-conditions
- User session created
- Auth token stored
- Analytics event logged

### Edge Cases to Consider
- TC-LOGIN-002: Invalid password
- TC-LOGIN-003: Non-existent email
- TC-LOGIN-004: SQL injection attempt
- TC-LOGIN-005: Very long password
</details> <details> <summary><strong>Example: Responsive Design Test Case</strong></summary>
## TC-UI-045: Mobile Navigation Menu

**Priority:** P1 (High)
**Type:** UI/Responsive
**Devices:** Mobile (iPhone, Android)

### Objective
Verify navigation menu works correctly on mobile devices

### Preconditions
- Access from mobile device or responsive mode
- Viewport width: 375px (iPhone SE) to 428px (iPhone Pro Max)

### Test Steps
1. Open homepage on mobile device
   **Expected:** Hamburger menu icon visible (top-right)

2. Tap hamburger icon
   **Expected:**
   - Menu slides in from right
   - Overlay appears over content
   - Close (X) button visible

3. Tap menu item
   **Expected:** Navigate to section, menu closes

4. Compare against Figma mobile design [link]
   **Expected:**
   - Menu width: 280px
   - Slide animation: 300ms ease-out
   - Overlay opacity: 0.5, color #000000
   - Font size: 16px, line-height 24px

### Breakpoints to Test
- 375px (iPhone SE)
- 390px (iPhone 14)
- 428px (iPhone 14 Pro Max)
- 360px (Galaxy S21)
</details>

"Testing shows the presence, not the absence of bugs." - Edsger Dijkstra

"Quality is not an act, it is a habit." - Aristotle

FAQ

What does the qa-test-planner skill do?

Generate comprehensive test plans, manual test cases, regression test suites, and bug reports for QA engineers. Includes Figma MCP integration for design validation.

How do I install qa-test-planner?

Run npx skills add https://github.com/softaworks/agent-toolkit --skill qa-test-planner in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/qa-test-planner/ (personal) or .claude/skills/qa-test-planner/ (project).

Which AI agents can use qa-test-planner?

Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.

Is qa-test-planner safe to install?

Security partners have reviewed it: Gen Agent Trust Hub flagged items to review; Socket flagged items to review; Snyk passed; Runlayer passed; ZeroLeaks passed. As with any skill, read the SKILL.md and bundled scripts before installing.

Who maintains qa-test-planner?

It is published by softaworks in softaworks/agent-toolkit. It has 4,342 recorded installs.

More from softaworks/agent-toolkit

View all →

mermaid-diagrams

softaworks/agent-toolkit

Comprehensive guide for creating software diagrams using Mermaid syntax. Use when users need to create, visualize, or document software through diagrams including class diagrams (domain modeling, object-oriented design), sequence diagrams (application flows, API interactions, code execution), flowcharts (processes, algorithms, user journeys), entity relationship diagrams (database schemas), C4 architecture diagrams (system context, containers, components), state diagrams, git graphs, pie charts, gantt charts, or any other diagram type. Triggers include requests to "diagram", "visualize", "model", "map out", "show the flow", or when explaining system architecture, database design, code structure, or user/application flows.

Docs & Writing5.1K installs

humanizer

softaworks/agent-toolkit

Remove signs of AI-generated writing from text. Use when editing or reviewing text to make it sound more natural and human-written. Based on Wikipedia's comprehensive "Signs of AI writing" guide. Detects and fixes patterns including: inflated symbolism, promotional language, superficial -ing analyses, vague attributions, em dash overuse, rule of three, AI vocabulary words, negative parallelisms, and excessive conjunctive phrases. Credits: Original skill by @blader - https://github.com/blader/humanizer

Docs & Writing4.4K installs

database-schema-designer

softaworks/agent-toolkit

Design robust, scalable database schemas for SQL and NoSQL databases. Provides normalization guidelines, indexing strategies, migration patterns, constraint design, and performance optimization. Ensures data integrity, query performance, and maintainable data models.

Data & Databases4.3K installs

writing-clearly-and-concisely

softaworks/agent-toolkit

Use when writing prose humans will read—documentation, commit messages, error messages, explanations, reports, or UI text. Applies Strunk's timeless rules for clearer, stronger, more professional writing.

Docs & Writing4.3K installs

skill-judge

softaworks/agent-toolkit

Evaluate Agent Skill design quality against official specifications and best practices. Use when reviewing, auditing, or improving SKILL.md files and skill packages. Provides multi-dimensional scoring and actionable improvement suggestions.

c4-architecture

softaworks/agent-toolkit

Generate architecture documentation using C4 model Mermaid diagrams. Use when asked to create architecture diagrams, document system architecture, visualize software structure, create C4 diagrams, or generate context/container/component/deployment diagrams. Triggers include "architecture diagram", "C4 diagram", "system context", "container diagram", "component diagram", "deployment diagram", "document architecture", "visualize architecture".

Popular testing & qa skills

View category →

tdd

mattpocock/skills

Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

Testing & QA1.2M installs

grilling

mattpocock/skills

Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.

Testing & QA996.2K installs

migrate-to-shoehorn

mattpocock/skills

Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.

Testing & QA484.1K installs

run-train

lllllllama/rigorpilot-skills

Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized trainoutputs/. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration.

Testing & QA337.8K installs

test-driven-development

obra/superpowers

Use when implementing any feature or bugfix, before writing implementation code

Testing & QA261.8K installs

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work

Testing & QA216.8K installs