role-qa-engineer

Provides: Risk-based test strategy, test level selection, coverage review questions, and flaky test triage.

Quick Reference

Goal: prove the behavior users depend on, not every implementation detail

Default mix: many fast unit tests, enough integration tests to cover boundaries, a few E2E checks for critical journeys

Never: chase a coverage percentage as the goal

Reference: skill:standards-testing for writing or reviewing the tests themselves

Workflow

1. Identify risk

Rank what deserves coverage before deciding how to test it:

• Critical user paths, data loss or corruption, permissions, payments, and irreversible actions.
• Recent regressions, complex branching, concurrency, and integration points.

Coverage effort follows risk. A utility function and a payment path do not deserve the same scrutiny.

2. Choose the test level

Read testing levels and patterns when choosing test boundaries or concrete test-case structures.

3. Define cases

Cover the happy path, boundary values (minimum, maximum, just inside, just outside), empty states, invalid input, permission failures, retries and timeouts, and migration or compatibility paths.

Then enumerate the categories that are easiest to skip:

• Hostile strings: unicode and emoji, whitespace (spaces, tabs, newlines), and interpreter metacharacters (', --, ;, <, >, &).
• Size: very long strings, large arrays, deeply nested payloads, large file uploads.
• Timing: two actors mutating the same resource, operations arriving out of order, and timeouts mid-operation.

At each integration point, name the specific failure the test should force rather than "it fails":

4. Evaluate quality

Tests should be deterministic, isolated, readable, and focused on behavior. Prefer explicit fixtures over hidden shared state, because shared state is what makes a suite order-dependent.

Coverage Review

Do not chase percentages blindly. A suite at 90% that never exercises the payment path is worse than one at 60% that does. Ask:

• Are the high-risk paths covered at the right level?
• Would these tests actually fail for the bug or regression we care about?
• Are mocks hiding integration risk?
• Are the slow or flaky tests worth their maintenance cost?
• Is there a smaller test that gives the same confidence?

Useful coverage tiers when a target is needed: critical paths such as auth, payments, and data integrity at 100%; business logic and error handling at 90% or above; general utilities and controllers at 80% or above. Treat these as a prompt for discussion, not a gate.

Flaky Test Triage

Classify the likely cause before changing anything:

• Time assumptions or fixed sleeps.
• Test order or shared mutable state.
• Async work that is not awaited.
• A dependency on an external service, the network, or the filesystem.
• Random data, time zones, locale, or direct clock use.

A test that fails only in CI is often exposing a real race that local timing hides. Do not add a retry until you have ruled that out.

Checklist

Before finishing QA work:

• The strategy maps identified risks to specific test levels
• Acceptance criteria have both positive and negative coverage
• Flaky or skipped tests have an owner and a stated reason
• Recommended commands or manual checks are explicit
• Mocks do not hide a boundary that needs an integration test

Integration with Other Skills

With standards-testing: apply the implementation conventions for the tests planned here.

With role-developer: hand off the case list for implementation alongside the feature.

With role-code-review: review test quality and coverage in a diff.

With role-security-auditor: turn findings into security regression tests.

With workflow-debugging: investigate a flaky or failing test whose cause is unknown.