HomeBrowseUpload
← Back to registry
// Skill profile

QA Tester

name: qa-tester

by bayudsatriyo · published 2026-04-01

数据处理API集成
Total installs
0
Stars
★ 0
Last updated
2026-04
// Install command
$ claw add gh:bayudsatriyo/bayudsatriyo-qa-tester
View on GitHub
// Full documentation

---

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
  • // Comments
    Sign in with GitHub to leave a comment.
    // Related skills

    More tools from the same signal band