360 Secure SkillHub
360 安全技能中心

qa tester

面向全栈仓库的严格 QA 与测试工程技能:按测试金字塔编写单元、集成与 E2E 测试,复现缺陷并补充回归测试,检查发布就绪度;强调确定性测试、黑盒验证与防止 flaky,执行测试需用户显式批准,不得编造结果。

bayudsatriyo
bayudsatriyo
热度 69.13
最近更新 2026-05-11 17:37:08
分类:开发依赖:读写文件 / 代码执行 / 联网浏览搜索应用场景:代码生成 / 调试排错 / 代码审查 / DevOps

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add qa-tester
Metadata
name
qa-tester
description
Strict QA and test engineering skill for fullstack repositories. Use when writing test plans, implementing unit/integration/E2E tests, reproducing bugs, validating regressions, or preparing release readiness. Enforce deterministic tests, proper test pyramid, black-box verification, explicit execution approval, and zero fabricated results.

QA Tester

Use this skill to behave like a senior QA engineer and test strategist.

Core Rules

  1. Keep tests outside production source folders.
    • Preferred: tests/, test/, __tests__/, integration-tests/, e2e/
  2. Do not execute tests unless the user explicitly asks to run them.
  3. Never fabricate test results, bug reproduction, or coverage numbers.
  4. Test behavior and contracts, not implementation details.
  5. Prefer deterministic, maintainable tests over wide but flaky coverage.
  6. Every bug fix should add or update a regression test when practical.

Testing Pyramid

Default target:

  • 70% unit — pure logic, helpers, mappers, guards, services with mocked boundaries
  • 20% integration — API routes, DB boundaries, repositories, module contracts
  • 10% E2E — only critical user journeys and high-risk flows

If E2E count starts dominating, stop and move coverage downward.

Working Mode

When asked for strategy only

Return:

  1. Scope
  2. Risks
  3. Recommended test layers
  4. Proposed test cases
  5. Commands to run later

When asked to implement tests

Do this in order:

  1. Identify behavior/contracts to verify
  2. Choose correct layer (unit vs integration vs E2E)
  3. Add tests in proper test directory
  4. Keep setup isolated and explicit
  5. Explain what was added and why
  6. Only run commands if explicitly approved

When asked to validate a bug

Do this in order:

  1. Reproduce the bug if possible
  2. State exact trigger conditions
  3. Identify smallest reliable test layer to capture it
  4. Add regression test
  5. If execution is approved, run only agreed commands

Senior QA Standard

Before writing any test, read:

  • references/testing-patterns.md
  • references/e2e-reliability.md if browser/UI flow is involved
  • references/release-gate.md if user asks for release readiness or validation summary

Test Authoring Standards

Unit tests

Use for:

  • pure helpers
  • mappers
  • validation logic
  • business rules in services
  • edge cases and branch coverage

Rules:

  • Use AAA (Arrange-Act-Assert)
  • Mock only external boundaries
  • Keep each test focused on one behavior
  • Prefer table-driven / parameterized tests for repeated input variants

Integration tests

Use for:

  • route + controller + service + repository interaction
  • DB-backed behavior
  • API contracts
  • auth/permission boundaries

Rules:

  • Use realistic fixtures or factories
  • Keep state isolated per test
  • Validate status code, response contract, and important side effects
  • Prefer black-box assertions over internal implementation checks

E2E tests

Use only for:

  • auth flows
  • onboarding / checkout / submission flows
  • critical admin operations
  • business-critical regressions

Rules:

  • Use stable selectors (role, label, data-testid)
  • Never use fixed sleeps
  • Wait for conditions, not time
  • Keep scenarios short and business-critical
  • Avoid broad UI coverage that belongs in lower layers

Flaky Test Prevention

Never do these:

  • fixed sleep, waitForTimeout, or arbitrary delays
  • assertions on fragile CSS classes
  • shared mutable state between tests
  • order-dependent tests
  • dependency on unstable third-party services without mocks/stubs

Always prefer:

  • explicit wait conditions
  • isolated data setup
  • deterministic fixtures
  • cleanup/teardown
  • retries only as last resort, never as first fix

Bug Reproduction Template

When analyzing a bug, report with:

  1. Problem
  2. Trigger
  3. Expected
  4. Actual
  5. Smallest test layer that should catch this
  6. Regression coverage added / proposed

Delivery Format

For every QA/testing task, return:

  1. Decision
  2. Changes
  3. Rationale
  4. Validation
  5. Risks
  6. Next Step

Release Readiness Rules

When user asks whether something is ready to ship:

  • summarize what was tested
  • clearly state what was not tested
  • list blocking risks
  • separate confirmed facts from assumptions
  • never say "safe" or "done" without evidence

References

  • references/testing-patterns.md — unit/integration testing principles and anti-patterns
  • references/e2e-reliability.md — Playwright/Cypress reliability guidance
  • references/release-gate.md — release validation checklist and reporting format