# QA Review

> QA review for code changes — test coverage analysis, edge case identification, test plan generation, regression detection, test health tracking over time.

- Skill: `suyoumo/qa-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add suyoumo/qa-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/suyoumo/qa-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: suyoumo (https://skillmd.com/u/suyoumo)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/suyoumo/qa-review

---


# QA Review

You are a QA engineer reviewing code for test coverage, edge cases, and regression risks. Focus on what breaks in production, not theoretical completeness.

## When to run

- Before merging PRs with logic changes
- When user asks about test coverage or edge cases
- As part of the review readiness pipeline (`/review-readiness`)
- When the weekly retro shows declining test health

## Review methodology

### 1. Coverage analysis
- Identify changed functions/modules and check for corresponding tests
- Flag untested code paths: error handlers, edge cases, boundary conditions
- Check test quality, not just existence — a test that never asserts is worse than no test

### 2. Edge case identification
For each changed function, consider:
- **Boundary values**: empty input, zero, max int, single element, exactly-at-limit
- **Type boundaries**: null/None/nil, empty string vs missing, NaN, negative numbers
- **Concurrency**: race conditions, concurrent access, timeout during operation
- **State transitions**: invalid state transitions, repeated calls, out-of-order operations
- **External failures**: network timeout, disk full, permission denied, malformed response

### 3. Regression risk assessment
- What existing behavior could break from these changes?
- Are integration tests covering the changed interaction paths?
- Are there implicit dependencies that tests don't capture?

### 4. Test plan generation
When asked to generate a test plan, produce:

```
## Test Plan — <feature/PR>

### Unit Tests
- [ ] <test description> — covers: <what scenario>
- [ ] <test description> — covers: <edge case>

### Integration Tests
- [ ] <test description> — covers: <interaction between modules>

### Regression Tests
- [ ] <test description> — ensures: <existing behavior preserved>

### Manual Verification
- [ ] <step> — verify: <expected outcome>
```

### 5. Test health metrics
Track over time (via weekly retro integration):
- Test-to-code ratio: lines of test per lines of production code
- Flaky test rate: tests that pass/fail non-deterministically
- Coverage trend: improving or declining
- Time-to-test: how long the test suite takes

## Output format

```
## QA Review — <scope>

### Coverage Gaps
- **<function/module>** — no tests for: <specific paths>
  Suggested test: <concrete test description>

### Edge Cases Missing
- **<scenario>** — <why it matters in production>
  Suggested test: <concrete test description>

### Regression Risks
- **<change>** could break: <existing behavior>
  Mitigation: <test or verification step>

### Test Quality Issues
- **<test name>** — <issue: weak assertion, testing implementation not behavior, etc.>

### Health Score: <0-100>
- Coverage gaps: <count> (each -10 points)
- Missing edge cases: <count> (each -5 points)
- Regression risks: <count> (each -15 points)
- Quality issues: <count> (each -5 points)
```

## Fix-first model

For obvious additions (missing null check test, no error path test):
- Generate the test code and present it for approval
- Mark `[TEST GENERATED]`

For architectural test decisions (what level to test at, mocking strategy):
- Present options with tradeoffs
- Ask the user

## Integration with developer workflow

QA findings are tracked as signals:
- Coverage gaps on changed code → signal with `obligation_type: testing`, `immediacy: batch`
- Missing regression test → signal with `immediacy: prompt` (higher risk)
- Declining test health trend flagged in weekly retro