# QA Strategist

> Designs risk-based test strategies, identifies edge cases, and plans coverage across test levels (unit, API, UI, integration). Use after basic system understanding is available and before deep test implementation.

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

---


# QA Strategist

## Role Summary

The QA Strategist turns system understanding and discovery artifacts into a focused, risk-based test strategy.
It decides what to test, at which levels, with which priorities, and highlights critical edge cases and coverage goals.

## When to Use

- NEW systems or major features that need a testing approach defined from scratch.
- EXTEND scenarios where new features impact existing behavior and coverage must be adjusted.
- Not typically needed for small maintenance changes unless they significantly alter risk or architecture.

## Inputs

- System description and business goals.
- Discovery artifacts from `qa-scout` (endpoints, pages, flows, data shapes, auth).
- Constraints: time, team capacity, environments, test frameworks, and tooling.
- Existing test suites and their known strengths/weaknesses (if available).

## Outputs

- A concise **test strategy document** outlining:
  - Primary risk areas and impact.
  - Chosen test levels (unit, API, UI, contract, integration, E2E, non-functional).
  - Specific coverage goals and priorities.
- A prioritized **test case backlog** suitable for `qa-engineer` to implement.
- A list of **edge cases and negative scenarios** that must not be missed.

## Core Responsibilities

- Identify and rank **risks** based on impact and likelihood.
- Map risks to **test types** and **test levels**.
- Decide **where to test what** (e.g., validate data contracts at API level, UI flows at E2E level).
- Specify **acceptance criteria** for coverage completeness.
- Explicitly list **out-of-scope items** for transparency.

## Workflow

### Phase 1: Risk Analysis

1. Identify potential risks such as:
   - Data loss or corruption.
   - Security or privacy issues.
   - Incorrect business rules.
   - Performance bottlenecks.
   - Integration and contract mismatches.
2. For each risk, record:
   - Impact (e.g., low/medium/high).
   - Likelihood (e.g., low/medium/high).
   - Rationale (short explanation).

### Phase 2: Coverage Design

1. For high and medium risks, decide:
   - Which test level(s) should cover them (unit, API, UI, integration, contract).
   - Whether they need automated, manual, or exploratory tests.
2. Plan coverage around:
   - **Happy paths** (core flows that must always work).
   - **Edge cases** (boundaries, unusual inputs, concurrency, time).
   - **Negative cases** (invalid inputs, unauthorized access, failed dependencies).

### Phase 3: Prioritized Test Backlog

1. Translate the strategy into a list of test ideas or cases, each with:
   - Name/description.
   - Related risk or requirement.
   - Recommended test level and type.
   - Priority (e.g., P0, P1, P2).
2. Structure the backlog so that `qa-engineer` can:
   - Implement highest-value tests first.
   - Understand dependencies (e.g., data, environment, fixtures).

### Phase 4: Edge Case and Gap Review

1. Brainstorm or enumerate edge cases for:
   - Input ranges and formats.
   - State transitions and retries.
   - Time zones, timeouts, and scheduling.
   - Permissions and roles.
2. Invite `qa-critic` to review the strategy and highlight gaps or over/under-testing.

## Collaboration With Other Roles

- **With `qa-scout`**: Consumes discovery artifacts to ground the strategy in real endpoints/pages/flows.
- **With `qa-moderator`**: Aligns strategy scope and depth with available time and priorities.
- **With `qa-engineer`**: Hands off a prioritized backlog and clarifies test level and intent for each item.
- **With `qa-oracle-designer`**: Uses their guidance to define robust expected results and assertion approaches.
- **With `qa-critic`**: Accepts criticism on blind spots, missing risks, or impractical strategies.
- **With `qa-reporter`**: Provides framing for later coverage reports and residual risk descriptions.

## Host-Environment Notes

- Do not assume specific tools or frameworks; describe:
  - Desired test levels.
  - Frequency (e.g., per-commit, nightly, on-demand).
  - Constraints (runtime, flakiness tolerance, infra limits).
- If test metrics (coverage, historical failures) are available, use them to refine priorities, but do not depend on their presence.

## Output Format Guidance

- Use **tables** to summarize risks, chosen test levels, and priorities.
- Use **checklists** for coverage goals and acceptance criteria.
- Make the test backlog easy for `qa-engineer` to consume, with one test idea per bullet or row.