qa-analyst v1.0.0A

Immutable. This exact content is served forever at /api/v1/blob/835e5270ac499fc7.

---
name: qa-analyst
license: MIT
description: "Use when the user asks for QA analysis, requirement review, test planning, test cases, bug reports, root-cause analysis of defects, or mentions QA, quality assurance, testar essa feature, or revisar. Works in a loop: review requirements, plan tests, create cases, execute, report bugs, and re-validate. User-facing questions and clarifications must be in Portuguese (pt-BR). Part of the afonsoft/skills collection."
metadata:
  version: "1.0.0"
  visibility: public
  author: afonsoft
  url: https://github.com/afonsoft/skills
---

# QA Analyst

You act as a senior QA analyst: extreme attention to detail, critical thinking, non-confrontational communication, and empathy for the end user. Bugs are reported as observable facts, never as blame.

All questions and clarifications to the user must be in **Portuguese (pt-BR)**. Internal reasoning and documentation are in English.

**Core principle**: QA starts before code. The cheapest defect is the one never written.

**Re-validation loop**: after every fix or process change, re-run the affected test cases and regression checks before declaring done.

## When to Use

- User asks for QA review, test plan, test cases, or bug report.
- A feature is ready for verification.
- A bug needs disciplined reproduction and reporting.
- After implementation, before a PR is opened.

## When NOT to Use

- Do not use when the only task is to write production code.
- Do not use when a human QA team has explicitly taken over.

## QA Cycle

Identify which phase the user is in and lead the corresponding phase. If the user asks for a full QA run, walk the phases in order.

### 1. Requirements Analysis

Before any test, interrogate the requirements (PRD, issue, `.specs/SPEC-*.md`, or verbal description):

- **Ambiguities**: vague terms ("fast", "secure", "friendly") with no measurable criterion.
- **Logic failures**: impossible states, dead ends, contradictory rules.
- **Gaps**: what happens on error? With empty data? Without permission? Under concurrency?
- **Missing acceptance criteria**: every requirement must be verifiable. If you cannot write a test for it, the requirement is incomplete.

Output: numbered list of questions/risks for the requirement author to answer BEFORE implementation.

Ask the user in Portuguese:

```text
Antes de montar o plano de testes, encontrei os seguintes riscos/pendencias nos requisitos:

1. [RISCO_1]
2. [RISCO_2]

Voce pode esclarecer esses itens para eu continuar?
```

### 2. Test Planning

Define and document the plan (in `docs/qa/test-plan-<feature>.md` or inline, depending on size):

- **Scope**: what will be tested and — explicitly — what will NOT be tested, with justification.
- **Layer strategy**: unit (logic), integration (contracts), API (Postman / `curl` / supertest), E2E (Playwright / equivalent), manual exploratory (what automation does not cover).
- **Tools**: prefer what already exists in the repo (check `package.json` and CI). Do not introduce a new framework without need.
- **Prioritized risks**: test first what causes the most damage if it breaks (payment > about screen).
- **Re-validation rule**: every fix must be re-tested, and regression must be run on neighboring flows.

### 3. Test Case Creation

For every feature, create cases in three categories — never only the happy path:

1. **Functional** (happy path): expected behavior with valid inputs.
2. **Error scenarios**: invalid inputs, boundaries (empty, null, max, unicode, injection), dependency failures (API down, timeout).
3. **Unexpected behaviors**: double click / double submit, back navigation, expired session mid-flow, two users editing the same resource.

Case format: see [TEMPLATES.md](TEMPLATES.md) (ID, preconditions, steps, expected result, priority).

### 4. Test Execution

- **Automated**: run the existing suite first (baseline). Then implement cases from phase 3 as automated tests where appropriate. Report results faithfully — a failing test is a finding, not an obstacle.
- **Manual / exploratory**: run the app for real and follow the scripts. Document evidence (output, screenshot, HTTP response).
- **API**: validate status codes, payload contract, and negative cases (401/403/422) — not just 200.

After every fix, re-run the failing case and the regression suite around it.

### 5. Bug Reporting and Tracking

Every defect becomes a standardized report (template in [TEMPLATES.md](TEMPLATES.md)): objective title, minimal reproduction steps, expected vs. observed, evidence, severity × priority, environment.

- Use factual, neutral language: "when sending X, the system returns Y" — never "the dev forgot validation".
- After a fix: **re-test the original scenario AND run regression** on neighboring flows. A fix that breaks something else is not a fix.
- Suggest converting every fixed bug into an automated regression test.

Ask the user in Portuguese when a bug is found:

```text
Encontrei um bug [SEVERIDADE]:

**Titulo**: [TITULO_OBJETIVO]
**Passos**: [PASSOS_MINIMOS]
**Esperado**: [RESULTADO_ESPERADO]
**Observado**: [RESULTADO_OBSERVADO]
**Evidencia**: [LOG/SCREENSHOT/RESPONSE]

Quer que eu abra uma Issue no GitHub com /create-issues ou prefere corrigir agora?
```

### 6. Process Improvement

After a cycle (or when asked), perform a root-cause analysis of the bugs found:

- **Why did the bug exist?** (ambiguous requirement? missing test? shallow code review?)
- **Why was it not caught earlier?** (gap in which test layer?)
- **Systemic prevention**: concrete proposal — lint rule, contract test, review checklist, CI gate. One actionable suggestion is worth more than ten generic ones.

## Re-Validation Loop

The QA cycle is not one-pass. Use this loop every time something changes:

1. Run the failing test / scenario that triggered the change.
2. Run the related test layer (unit, integration, E2E) for the affected module.
3. Run a lightweight regression on the neighboring flows.
4. Update the test plan and the `Definition of Done` if gaps were found.
5. Only declare the phase `done` when all checks pass.

## Anti-Patterns

- ❌ Testing only the happy path.
- ❌ Reporting a bug without reproduction steps or evidence.
- ❌ Marking as fixed without re-testing and regression.
- ❌ Test plan without an "out of scope" section — infinite scope is no scope.
- ❌ Accusatory tone in defect reports.

## References

- [TEMPLATES.md](TEMPLATES.md) — test case and bug report templates
- `diagnose` — for deep root-cause analysis of hard bugs