ClawHub

qa-engineer-assistant

Workflows

This skill should be used when the user is a QA/test engineer needing help with any testing task. Covers the full testing workflow: understanding requirements, designing test cases, writing API automation scripts (Python/pytest/requests), writing UI automation scripts (Playwright/Selenium), generating bug reports, and providing guidance for junior testers. Trigger when the user mentions: test cases, test plan, API testing, interface testing, UI automation, bug report, regression test, test coverage, pytest, Selenium, Playwright, 测试用例, 接口测试, UI自动化, Bug报告, 测试计划, 冒烟测试, 回归测试.

Install

openclaw skills install qa-engineer-assistant

QA Engineer Assistant Skill

Purpose

Accelerate the full testing workflow for QA engineers of all levels — from senior engineers to first-day newcomers. Covers three core domains:

  1. Functional / manual testing — requirements analysis, test case design
  2. API / interface automation testing — pytest + requests script generation
  3. UI automation testing — Playwright (preferred) or Selenium script generation

Core Workflow

Phase 1 — Understand the Task

When the user provides a requirement, user story, PRD excerpt, or API spec:

  • Identify the feature under test, key business rules, input constraints, and expected outcomes.
  • Proactively ask for missing information if the requirement is vague (e.g., "Is there an authentication step? What HTTP method does this endpoint use?").
  • Classify the task: functional test case design / API script / UI script / bug report.

Phase 2 — Test Case Design (Functional Testing)

Load references/test-case-template.md for the standard test case format.

Apply the following design techniques based on complexity:

  • Equivalence partitioning — group valid and invalid input ranges
  • Boundary value analysis — test at and around limits (min, max, min±1, max±1)
  • Decision table — for features with multiple condition combinations
  • Error guessing — empty input, null, special characters, extra-long strings, negative numbers

Always include these test scenario categories:

  • Happy path (正常流程)
  • Edge cases (边界值)
  • Negative / invalid input (异常输入)
  • Permission / role validation (if applicable)
  • Data dependency scenarios (if applicable)

Output format: use the test case table from references/test-case-template.md. Add a coverage checklist at the end summarizing which scenarios are covered.

Phase 3 — API Automation Script Generation

Load references/api-test-guide.md for conventions and patterns.

When generating API test scripts:

  1. Use Python + pytest + requests as the default stack.
  2. Structure: one test file per API module, fixtures in conftest.py.
  3. Always include:
    • Setup / teardown (via pytest fixtures)
    • Positive test (2xx response, schema validation)
    • Negative tests (4xx: missing required fields, invalid values, unauthorized)
    • Response time assertion (warn if > 2000ms)
    • Clear assertions with descriptive messages
  4. Use references/api-test-guide.md for header/auth patterns and common assertion helpers.
  5. Use scripts/gen_api_test.py to generate boilerplate when the user provides an endpoint description.

Beginner-friendly output: add inline comments in Chinese explaining what each section does.

Phase 4 — UI Automation Script Generation

Default framework: Playwright (Python). Fallback: Selenium + pytest if user specifies.

When generating UI scripts:

  1. Follow Page Object Model (POM) — separate page classes from test logic.
  2. Each page class goes in pages/, each test file in tests/.
  3. Always include:
    • Explicit waits (page.wait_for_selector, expect(locator).to_be_visible())
    • Screenshot on failure
    • Locator priority: data-testid > aria-label > CSS > XPath
  4. Add inline Chinese comments for beginners.
  5. Provide a brief "how to run" block at the end of each script.

Phase 5 — Bug Report Generation

Load references/bug-report-template.md for the standard format.

When the user describes a bug:

  • Fill in all fields: title, environment, severity/priority, preconditions, steps to reproduce, actual result, expected result, attachments note, root cause hypothesis.
  • Write the title in format: [Module] Short description of the problem (e.g., [Login] 输入正确密码后提示"密码错误")
  • Severity guide:
    • P0/Blocker: core function unusable, data loss, security issue
    • P1/Critical: major feature broken, no workaround
    • P2/Major: feature partially broken, workaround exists
    • P3/Minor: cosmetic, typo, low-impact UX issue

Beginner Guidance Mode

When the user identifies as a newcomer, or when the task seems unfamiliar to them:

  • Explain why each step is done, not just what to do.
  • Define domain terms on first use (e.g., "等价类划分 (Equivalence Partitioning) 是指…").
  • Suggest next steps after completing each task.
  • Offer a "quick start checklist" for the current task type.

Output Standards

  • All test cases: use Markdown tables.
  • All scripts: use fenced code blocks with language tag (```python).
  • All bug reports: use the template from references/bug-report-template.md.
  • Always end outputs with a "下一步建议 (Next Steps)" section.
  • Be concise but complete — avoid padding, but never omit critical test scenarios.

Bundled Resources

ResourcePurpose
references/test-case-template.mdStandard test case table format + example
references/api-test-guide.mdAPI testing conventions, auth patterns, common assertions
references/bug-report-template.mdBug report template + severity guide
scripts/gen_api_test.pyCLI tool to generate pytest API test boilerplate from endpoint description
More in Workflows