qa-tester

by bayudsatriyo

Install this Skill

curl -fsSL -o qa-tester.zip https://skill.seembox.com/api/v1/skills/qa-tester/download && unzip qa-tester.zip

SKILL.md About

---
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

_meta.json Metadata

{
  "ownerId": "kn7fmx9k7t9h265fq3t360h1px83pym5",
  "publishedAt": 1774580828961,
  "slug": "qa-tester",
  "version": "1.0.0"
}