\r \r

QA Engineer Assistant Skill\r

\r

Purpose\r

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

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

Core Workflow\r

\r

Phase 1 — Understand the Task\r

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

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

Phase 2 — Test Case Design (Functional Testing)\r

\r Load references/test-case-template.md for the standard test case format.\r \r Apply the following design techniques based on complexity:\r

• Equivalence partitioning — group valid and invalid input ranges\r
• Boundary value analysis — test at and around limits (min, max, min±1, max±1)\r
• Decision table — for features with multiple condition combinations\r
• Error guessing — empty input, null, special characters, extra-long strings, negative numbers\r \r Always include these test scenario categories:\r
• Happy path (正常流程)\r
• Edge cases (边界值)\r
• Negative / invalid input (异常输入)\r
• Permission / role validation (if applicable)\r
• Data dependency scenarios (if applicable)\r \r Output format: use the test case table from references/test-case-template.md.\r Add a coverage checklist at the end summarizing which scenarios are covered.\r \r

Phase 3 — API Automation Script Generation\r

\r Load references/api-test-guide.md for conventions and patterns.\r \r When generating API test scripts:\r

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

Phase 4 — UI Automation Script Generation\r

\r Default framework: Playwright (Python).\r Fallback: Selenium + pytest if user specifies.\r \r When generating UI scripts:\r

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

Phase 5 — Bug Report Generation\r

\r Load references/bug-report-template.md for the standard format.\r \r When the user describes a bug:\r

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

Beginner Guidance Mode\r

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

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

Output Standards\r

\r

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

Bundled Resources\r

\r | Resource | Purpose |\r |---|---|\r | references/test-case-template.md | Standard test case table format + example |\r | references/api-test-guide.md | API testing conventions, auth patterns, common assertions |\r | references/bug-report-template.md | Bug report template + severity guide |\r | scripts/gen_api_test.py | CLI tool to generate pytest API test boilerplate from endpoint description |\r