QA Review

QA Review

Review quality strategy the way a strong QA engineer would: choose the right test layers, verify the tests are readable and deterministic, and make failures easy to act on.

When to Use

• A feature or PR needs a QA-oriented review before merge or release
• Test coverage exists, but you are not sure it is at the right pyramid level
• A team needs a repeatable checklist for API, UI, regression, or performance coverage
• Bug reports or CI failures are noisy and need better quality standards

When NOT to Use

QA Model

Balance the test pyramid first:

If a change leans too heavily on slow end-to-end tests or skips contract-level checks entirely, treat that as a QA design issue, not just a missing test.

Workflow

1. Define the quality risk

Before reading tests, ask:

1. what can break for the user or operator?
2. which layer should catch it first?
3. what would make a failure actionable in CI?

Use that to decide whether you primarily need unit, integration, E2E, or performance evidence.

2. Inspect the current test surface

rg -n "describe\\(|test\\(|it\\(" . -g "*.{test,spec}.{js,jsx,ts,tsx}"
rg -n "def test_|class Test" . -g "*_test.py" -g "test_*.py"
rg -n "@playwright/test|cypress|selenium" .

Check whether the tests already map to the right layer or whether important paths are covered only indirectly.

3. Review test case quality

Prefer names that read as standalone behavior statements:

• should return 404 when product id does not exist
• given an expired token, when the user calls /me, then it returns 401

Flag names like test1, works, or implementation-detail phrasing that makes failures harder to interpret. Use the break-naming, real-behavior, and mutation-check criteria from tdd-workflow to verify that each test can detect the regression it claims to cover.

For assertions:

• prefer exact expected values over truthiness
• prefer specific matchers over generic equality
• keep one logical behavior per test when practical
• check both exception type and message for failure-path tests

4. Review data isolation and mocks

Look for:

• factories or builders instead of repeated raw fixture blobs
• minimal test data shaped only around the behavior under review
• unique IDs or reset hooks to prevent shared-state collisions
• mocking at the boundary (HTTP client, DB adapter, queue), not deep inside the core logic

Treat random sleeps, global state reuse, and order-dependent tests as reliability bugs.

5. Review boundary coverage

For APIs, verify:

• status code
• response schema
• headers
• authn/authz cases
• boundary inputs
• error-body consistency
• idempotency where relevant

For UI or E2E coverage, verify:

• user-visible behavior rather than implementation details
• accessible selectors first (role, label, then test-id)
• explicit waits instead of fixed sleeps
• isolated and stable execution environment

For performance-sensitive work, verify:

• explicit SLOs or target latency/throughput expectations
• realistic data volume
• distinction between load, stress, and soak concerns
• regression tracking over time instead of one-off anecdotes

6. Review CI and bug reporting readiness

A strong QA pass should leave behind:

• fast tests on every commit
• slower suites on PR, merge, or scheduled gates
• visible failure output with the exact broken test and reason
• retained artifacts such as traces, screenshots, JUnit XML, or coverage output

Bug reports should include:

1. precise title
2. environment
3. numbered repro steps
4. expected result
5. actual result
6. severity
7. relevant attachments

Output Template

## QA Review

### Coverage Shape
- ...

### Test Quality
- ...

### Reliability Risks
- ...

### Missing Cases
- ...

### CI / Reporting Gaps
- ...

### Recommended Next Step
1. ...
2. ...
3. ...

Review Checklist

• The changed behavior is covered at the right test-pyramid layer
• Test names are readable and behavior-focused
• Tests are deterministic and isolated
• Mocks are boundary-level and reset between tests
• API or UI boundary cases are covered where relevant
• CI output and artifacts would make a failure actionable

Common Rationalizations

See Also

• tdd-workflow - write the first failing tests before implementation
• eval-harness - evaluate LLM or agent workflows with tracked test cases
• e2e-testing - build and run critical user-flow automation
• test-coverage - measure and close structural coverage gaps