Token导航 LogoToken导航

Agent Skill · 开发

qa-test-planner(质量保证测试计划员)

用于辅助测试设计、自动化测试、用例整理和回归验证。它适合让 Agent 编写单元测试、端到端测试、测试计划或根据失败日志定位问题。使用时需要确认项目测试框架、运行命令和夹具数据,避免为了通过测试而改坏真实逻辑;涉及浏览器或外部服务时,应区分本地模拟、测试环境和生产环境。

qa-test-planner 是开发类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为接触敏感数据;许可证信息还不明确,第三方扫描已通过,按安装量在开发类的 21,746 个 Skill 里排第 12,454。

总安装 1,273周安装 52GitHub Stars 123下载 408核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
unknown

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:qa-test-planner(质量保证测试计划员)
来源仓库:https://github.com/fugazi/test-automation-skills-agents
仓库路径:skills/qa-test-planner
安装命令:
npx skills add https://github.com/fugazi/test-automation-skills-agents --skill qa-test-planner
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/fugazi/test-automation-skills-agents --skill qa-test-planner

这个 Skill 是做什么的

开发类 Skill 面向写代码、改代码和排查问题,一般会读写仓库文件,部分还会执行构建或测试命令。

qa-test-planner 用于辅助测试设计、自动化测试、用例整理和回归验证,适合让 Agent 编写测试计划或分析失败日志。适用于需要系统化测试策略和用例管理的开发项目。使用时需结合项目现有测试框架,确认运行命令和数据夹具。避免仅为了通过测试而修改核心逻辑,确保测试反映真实行为。

适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

来源仓库内路径:skills/qa-test-planner

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/fugazi/test-automation-skills-agents --skill q…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要接触敏感数据,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

qa-test-planner 怎么安装?

在终端执行 npx skills add https://github.com/fugazi/test-automation-skills-agents --skill qa-test-pla…。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

qa-test-planner 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

qa-test-planner 需要什么权限?

权限级别是接触敏感数据。该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

qa-test-planner 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

qa-test-planner 用的人多吗?

公开数据是累计安装 1,273 次,近一周安装 52 次,下载 408 次,GitHub 123 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

qa-test-planner 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 第三方扫描已通过,常见的高风险行为没有命中。

先想清楚的地方

  • 需要接触敏感数据,装到常用环境前要先评估影响面。
  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理开发类任务、又不想每次都手写提示词的人。

不太适合

  • 环境里有大量密钥、凭证,不方便给第三方 Skill 读取的人。
  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

开发类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
skill-vetter

技能审查员 · OpenClaw

8,779,018986操作浏览器MIT-0通过
ontology

本体论 · OpenClaw

6,636,960576只读MIT-0通过
entra-app-registration

内部应用程序注册 · Codex、Claude

6,631,872764接触敏感数据未明确通过
entra-app-registration

内部应用程序注册 · Codex、Claude

3,757,680201接触敏感数据未明确通过
nano-banana-pro

纳米香蕉专业版 · OpenClaw

3,526,898364接触敏感数据MIT-0有提醒
qa-test-planner

质量保证测试计划员 · 本页

1,273123接触敏感数据未明确通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

QA Test Planner

A comprehensive skill for QA Automation engineers to create test plans, generate manual test cases, build automated Playwright tests, create regression test suites, validate UI with browser automation, 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 using the test-plan.md template"

Generate test cases:

"Generate manual test cases for the checkout flow using the test-case.md template"

Create automated Playwright tests:

"Create Playwright automated tests for the login flow using the playwright-test.md template"

Validate UI with browser:

"Navigate to the login page and validate all form elements are visible using Playwright MCP"

Build regression suite:

"Build a regression test suite for the payment module using test-case.md templates grouped by priority"

Create bug report:

"Create a bug report for the form validation issue using the bug-report.md template"

Quick Reference

TaskTemplateTime
Test Plantemplates/test-plan.md10-15 min
Test Casetemplates/test-case.md5-10 min each
Automated Testtemplates/playwright-test.md5-15 min each
Bug Reporttemplates/bug-report.md5 min

When to Use This Skill

Use this skill when you need to:

  • Create or review test plans and test strategies
  • Generate test cases from requirements or user stories
  • Write bug reports with clear reproduction steps
  • Build regression suites with risk-based selection
  • Implement Playwright automation with best practices
  • Document test execution and results
  • Conduct exploratory testing sessions
  • Validate UI elements with browser automation

Prerequisites

RequirementNotes
Node.js 18+Required for Playwright automation
Playwrightnpm init playwright@latest for automation
Text editorFor creating/editing markdown files
GitRecommended for testware version control
Playwright MCPOptional, for browser-based validation

How It Works

Your Request
    │
    ▼
┌─────────────────────────────────────────────────────┐
│ 1. ANALYZE                                        │
│    • Parse feature/requirement                      │
│    • Identify test types needed (manual/automated)  │
│    • Determine scope and priorities                 │
├─────────────────────────────────────────────────────┤
│ 2. SELECT TEMPLATE                                │
│    • Choose appropriate template from assets/        │
│    • Review template structure and sections         │
│    • Identify placeholders to fill                 │
├─────────────────────────────────────────────────────┤
│ 3. CUSTOMIZE                                      │
│    • Fill in placeholders with project details      │
│    • Add specific test steps and scenarios         │
│    • Apply Playwright best practices               │
├─────────────────────────────────────────────────────┤
│ 4. EXECUTE (with Playwright MCP)                 │
│    • Navigate and interact with browser             │
│    • Capture screenshots and evidence               │
│    • Validate UI elements and behavior              │
├─────────────────────────────────────────────────────┤
│ 5. VALIDATE                                       │
│    • Check completeness                             │
│    • Verify traceability                            │
│    • Ensure actionable steps                        │
└─────────────────────────────────────────────────────┘
    │
    ▼
QA Deliverable Ready

Workflows

1) Create a Test Plan

  1. Use templates/test-plan.md as your starting point
  2. Identify test objectives, scope, assumptions, and constraints
  3. Define test levels and types (functional, UI, performance, etc.)
  4. Specify environments, test data, tooling, and configuration needs
  5. Define entry/exit criteria, deliverables, and reporting cadence
  6. Add a risk matrix and mitigation actions
  7. Prioritize testing accordingly (risk-based testing)

Template: templates/test-plan.md

2) Generate Test Cases

  1. Use templates/test-case.md for individual test cases
  2. Convert requirements into test conditions (what to test)
  3. Pick a test design technique:

- Equivalence partitions and boundary values for inputs - Decision tables for rule combinations - State transitions for lifecycle/flows - Use-case/scenario tests for end-to-end journeys

  1. Write test cases that are atomic, unambiguous, and traceable
  2. Add expected results that are observable and measurable
  3. Add priority and risk tags to support risk-based regression
  4. Mark automation candidates using stability + value criteria

Templates:

3) Implement Automation Test Scripts (Playwright)

  1. Use templates/playwright-test.md as a template
  2. Keep tests readable and aligned with test cases
  3. Prefer stable locators (e.g., getByTestId) over brittle selectors
  4. Avoid arbitrary sleeps; rely on Playwright auto-waits and explicit assertions
  5. Make tests independent (setup preconditions explicitly)
  6. Use tagging in test titles (e.g., @smoke, @regression) for suite runs
  7. Capture artifacts for triage (screenshots/video/trace) when debugging

Template: templates/playwright-test.md

4) Build and Maintain Regression Suites

  1. Use templates/regression-suite.md to define the suite
  2. Define suite tiers: smoke (critical paths), sanity (build verification), regression (broad), full (release)
  3. Select tests using risk + frequency + criticality + defect history
  4. Tag tests consistently and document selection rules
  5. Review the suite regularly: remove obsolete coverage, add coverage for escaped defects

Template: Use individual test-case.md templates grouped by priority

5) Create Bug Reports

  1. Use templates/bug-report.md as your starting point
  2. Reproduce reliably; reduce to minimal steps
  3. Note variability (frequency) and scope
  4. Capture environment details (build/app version, OS, browser/device, account/role)
  5. Describe expected vs actual behavior
  6. Include impact; set severity and priority consistently
  7. Attach evidence (screenshots, console logs, network traces, Playwright trace)
  8. Track lifecycle: triage notes, owner, fix version, verification steps

Template: templates/bug-report.md


Core Deliverables

1. Test Plans

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

Template: templates/test-plan.md

2. Manual Test Cases

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

Templates:

3. Regression Suites

  • Smoke tests (15-30 min) - P0 tests only
  • Full regression (2-4 hours) - P0, P1, P2 tests
  • Targeted regression (30-60 min) - Tests for specific feature
  • Execution order by priority (P0 first, then P1, then P2)

Template: Use individual test-case.md templates grouped by priority

4. Automated Playwright Tests

  • Role-based locator strategies
  • Web-first assertions
  • Page Object Model structure
  • test.step() grouping for readability
  • Screenshot capture on failure

Template: templates/playwright-test.md

5. Browser Validation (via Playwright MCP)

  • Live UI element verification
  • Screenshot capture for evidence
  • Console log inspection
  • Form interaction testing
  • Responsive viewport validation

6. Bug Reports

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

Template: templates/bug-report.md


Security Guidelines

Credential Handling

NEVER embed real credentials in test cases or code. Use placeholders instead:

Instead ofUse
test@example.com / Test123!${TEST_USER_EMAIL} or process.env.TEST_USER_EMAIL
password: "actualpassword"password: "${TEST_PASSWORD}" (from env)
Hardcoded secretsEnvironment variables via .env files

Test data best practices:

  • Use test accounts provisioned via API or admin panel
  • Store credentials in environment variables
  • Use Faker.js or similar for generated test data
  • Never commit real credentials to version control

URL Navigation Safety

When using Playwright MCP to validate external/untrusted URLs:

  1. Verify the URL is from a trusted domain before navigating
  2. Avoid executing arbitrary JavaScript from untrusted sources
  3. Use sandboxed environments when testing third-party applications
  4. Do NOT navigate to URLs provided by untrusted user input without validation

Input Sanitization

All user inputs should be:

  • Validated for expected format
  • Escaped when used in generated code
  • Never passed directly to eval() or shell execution

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
Embedding credentialsSecurity riskUse environment variables

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 uses placeholders (no hardcoded credentials)
  • Priority assigned

Automated Tests:

  • Role-based locators used
  • Web-first assertions implemented
  • Page Object Model applied
  • test.step() grouping for clarity
  • Error handling and screenshots
  • Credentials loaded from environment variables

Bug Reports:

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

Templates

Available Templates

TemplatePurposeFormat
test-plan.mdISTQB-aligned test plan structureMarkdown
test-case.mdIndividual test case with full sectionsMarkdown
bug-report.mdDetailed defect reportMarkdown
playwright-test.mdPlaywright test template with best practicesMarkdown

Template Usage

All templates are located in templates/. To use them:

  1. Copy the template to your project directory
  2. Fill in placeholders (marked with [brackets] or ${VARIABLE})
  3. Customize sections based on your specific needs
  4. Remove or add sections as appropriate
  5. Save and version control the completed document

References


Examples

Request:

"Create a test case for user login with valid credentials using the test-case.md template"

Result: The AI will:

  1. Open templates/test-case.md
  2. Fill in the placeholders with specific details:

- TC-ID: TC-LOGIN-001 - Title: Verify valid user login with correct credentials - Priority: P0 (Critical) - Type: Functional - Objective: Verify users can successfully login with valid credentials - Preconditions: User account exists in test environment; Browser cookies cleared - Test Steps: Fill with specific login steps - Test Data: Use ${TEST_USER_EMAIL} and ${TEST_USER_PASSWORD} placeholders

  1. Provide the completed test case markdown file

Request:

"Create a bug report for a login form validation issue using the bug-report.md template"

Result: The AI will:

  1. Open templates/bug-report.md
  2. Generate a unique bug ID (e.g., BUG-1715345678)
  3. Fill in the placeholders:

- Title: Login form accepts invalid email format - Severity: High - Priority: P1 - Environment: Fill with actual OS, browser, build details - Steps to Reproduce: Add specific, reproducible steps - Expected vs Actual: Clear description of the issue - Impact: Describe user and business impact

  1. Provide the completed bug report markdown file

Request:

"Create Playwright tests for the login flow using the playwright-test.md template"

Result: The AI will:

  1. Open templates/playwright-test.md
  2. Customize the test describe block for login functionality
  3. Add specific test cases:

- TC-LOGIN-001 @smoke @regression - Valid login - TC-LOGIN-002 @regression @negative - Invalid credentials - TC-LOGIN-003 @regression @boundary - Password validation

  1. Implement test steps using Playwright best practices:

- Role-based locators (getByRole) - Web-first assertions (toBeVisible, toHaveText) - test.step() grouping for readability

  1. Add security notes about environment variables
  2. Provide the completed markdown template with TypeScript code examples

Best Practices

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

Security Best Practices

DO:

  • Use environment variables for credentials
  • Use test accounts provisioned for testing
  • Validate URLs before navigating
  • Report suspicious content

DON'T:

  • Embed real credentials in code
  • Navigate to untrusted URLs
  • Execute arbitrary JavaScript from user input
  • Commit secrets to version control

Quality Gates (Self-Check)

  • Test plan includes scope, approach, risks, environments, entry/exit criteria, deliverables, and metrics
  • Test cases are traceable, atomic, deterministic, and include clear oracles and data
  • Automation is maintainable (stable locators, minimal flake, independent tests, clear assertions)
  • Regression is risk-based, tagged, and curated with clear add/remove rules
  • Bug reports are reproducible, actionable, and contain evidence + environment + impact

Troubleshooting

ProblemCauseSolution
Test cases lack traceabilityMissing requirement IDsAdd requirement_id column; link to user stories/ACs
Bug reports get rejectedInsufficient reproduction stepsUse minimal steps; include exact data and environment
Regression suite too slowToo many tests, no prioritizationApply risk-based selection; tier into smoke/sanity/full
Flaky automated testsUnstable locators or timingUse data-testid; avoid sleeps; use Playwright auto-waits
Test estimates are wrongScope creep, missing risksAdd contingency; re-estimate when scope changes

Common Rationalizations

Common shortcuts and "good enough" excuses that erode test quality — and the reality behind each.
RationalizationReality
"Test plans are documentation theater"A good test plan prevents scope creep, missed scenarios, and misaligned expectations before testing begins.
"We can figure out test cases as we go"Ad-hoc testing leaves gaps. Structured test cases ensure systematic coverage and traceability.
"Bug reports can be informal"Reproducible bug reports with exact steps save hours of back-and-forth between tester and developer.
"Estimation is just guessing"Test estimation techniques (function point analysis, Delphi method) improve accuracy and credibility.
"Regression suites maintain themselves"Without curation, suites grow bloated and slow. Regular review and pruning are mandatory.
"Templates slow us down"Templates ensure nothing is forgotten and standardize quality across the team.

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

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


Verification

After completing this skill's workflow, confirm:

  • Test strategy document created — Covers scope, approach, resources, schedule, and risks
  • Test levels defined — Unit, integration, E2E, and acceptance levels with criteria
  • Entry/exit criteria documented — Clear definition of when testing starts and ends
  • Risk-based prioritization — Tests prioritized by impact x likelihood
  • Environment requirements listed — Hardware, software, data, and network requirements
  • Defect management process defined — How bugs are reported, tracked, and resolved
  • Stakeholder sign-off — Test plan reviewed and approved by relevant stakeholders

平台分布

Codex

34.69%
按下载量换算142

Claude

29.16%
按下载量换算119

Cursor

18.6%
按下载量换算76

Gemini CLI

9.14%
按下载量换算37

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

接触敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills