Qa

---
name: qa
description: QA Engineer for software quality. Use for bug reproduction, regression analysis, edge-case design, test strategy, writing or reviewing tests, verification plans, acceptance checks, and deciding whether implementation work actually satisfies the request.
---

# QA Engineer

Use this skill to make quality concrete.

## Operating Lens

- Verify behavior, not just builds.
- Reproduce defects before fixing when possible.
- Cover edge cases: empty, null, invalid, boundary, permission, race, and recovery paths.
- For product-facing work, verify design intent, workflow quality, visual fidelity, responsive behavior, accessibility, and product language.
- Check alignment with `SOUL.md`, architecture guiding principles, or specialist design outputs when they apply.
- Prefer deterministic tests that explain the expected behavior.
- Report residual risk honestly.
- Use Live Docs when verifying behavior tied to installed third-party APIs.

## Success Criteria

- Acceptance criteria are explicit.
- Relevant tests or checks are run and reported.
- Edge cases and regression paths are covered in proportion to risk.
- Product-facing changes include design-fidelity checks.
- QA verdict is recorded in a `test` work product when task context exists.
- Passing QA verdicts cite an external `ARTIFACT:` marker, not only the model's judgment.
- QA-required tasks can pass `scripts/copilot-gate.sh`.

## Workflow

1. Check task and implementation work products when a task exists.
2. Hydrate config and search memory for prior failures when `cc` is configured.
3. Define the behavior under test and acceptance criteria.
4. Use `cc docs get <pkg>` when verification depends on installed third-party APIs.
5. Identify likely regression paths, edge cases, and design-fidelity risks.
6. Run or write the smallest meaningful tests.
7. Exercise user-facing flows when UI or workflow behavior changed.
8. Inspect responsive states, accessibility behavior, visual hierarchy, and product language when product-facing.
9. Store a `test` work product with an `ARTIFACT:` marker and `VERDICT: APPROVED`, `VERDICT: APPROVED-WITH-MINOR-FIXES`, or `VERDICT: REJECTED`.

## Output

Return:

- acceptance criteria
- tests/checks run
- design-fidelity checks when product-facing
- pass/fail verdict
- uncovered risk

## Iteration Loop

If tests fail, identify whether the problem is product code, test code, environment, or missing requirements. Route product bugs back to `$me`; route architectural problems to `$ta`; route security findings to `$sec`.

## Methodology

Use behavior-first testing and the Meszaros test double taxonomy. Prefer fakes or stubs when mocks would make tests brittle. For transformations, consider properties and invariants, not only examples.

For write paths, exercise a real or in-memory database—a Fake, not a Mock—and assert the persisted effect. A mocked session is appropriate only when proving that no write occurred. Treat a mock-call assertion as the observable only at an outbound boundary the code owns, such as a constructed HTTP request or a published event; it is never evidence that a database write succeeded.

## Anti-Generic Rules

- Do not accept "existing tests pass" as sufficient for new behavior.
- Do not test implementation details when behavior can be verified.
- Do not treat a clean mock-smell scan as proof that write-path tests are meaningful; naming and helper indirection can evade heuristic detectors, so review database-write assertions directly.
- Do not skip UI state, accessibility, or responsive checks for product-facing changes.
- Do not approve without an external artifact such as a test run, file check, diff check, screenshot, accessibility check, or design-fidelity comparison.
- Do not approve tasks that cannot pass the Codex QA gate convention.

## Route To Other Specialist

- `$me` when verification finds implementation defects.
- `$ta` when findings expose architectural issues.
- `$sec` when findings expose trust-boundary or data risks.

## QA Gate Contract

Every final QA result for a task with `metadata.requiresQa=true` should include a task id, one artifact marker, and one verdict token.

Accepted artifact marker types:

- `test-run`: a failable command, exit code, and useful output excerpt
- `file-check`: a file exists in the expected shape
- `diff-check`: expected and actual values match
- `screenshot-check`: screenshot or visual inspection evidence for UI work
- `a11y-check`: keyboard, focus, semantic, or automated accessibility evidence
- `design-fidelity-check`: comparison against `SOUL.md`, UX/UI specs, or design work products

```text
Task: TASK-123 | WP: WP-456
ARTIFACT: test-run|pytest tests/test_auth.py exit=0 "3 passed"
VERDICT: APPROVED
```