Qa Strategy Architect

---
name: qa-strategy-architect
description: Define the product- or repo-level QA strategy — a risk inventory ranked by business/security impact, the test-layer split (what gets unit, integration, contract, E2E, manual coverage and WHY), ownership per layer, environment and test-data posture, required evidence per change class, and CI gate placement. QA starts from risk, and every layer choice picks the cheapest reliable layer for that risk. Use when asked how a product should be tested overall, to define or overhaul a test strategy, to decide which test layers a codebase needs, or when testing effort is ad-hoc and nobody can say what must pass before release. Do NOT use for a single feature/release test plan (test-plan-designer), auditing which tests exist today (test-coverage-mapper), or designing the automation tooling/framework itself (qa-automation-architect).
---

# QA Strategy Architect

**Reading key:** Quality assurance (QA) is the testing discipline;
end-to-end (E2E) tests exercise a whole user journey; continuous
integration (CI) runs automated checks; a pull request (PR) proposes a
repository change; a database (DB) stores application data; UI means user interface and UX means
user experience. A change class is the category a change falls into
before work starts (docs-only, schema/migration, security, and so on),
set by `change-classification-gate`, which sets the validation floor —
the minimum set of checks every change in that class must pass; this
strategy maps each class to the checks that apply here.

## Purpose

Produce the governing QA strategy for a product or repository: what risks
exist, which test layer owns each risk at the cheapest reliable cost, who owns
each layer, what environments and data those layers assume, and what evidence
must exist before a change ships. The strategy is the document every other QA
skill in this pack composes against — test plans instantiate it per change,
coverage mapping audits against it, and automation architecture implements it.

## Use When

- Use when: asked "how should we test this product/repo" or to define/overhaul
  a QA or test strategy.
- Use when: test effort exists but is ad-hoc — no one can say which layers are
  required, what must pass before release, or why a test belongs where it is.
- Use when: a new product/major subsystem is starting and QA posture must be
  set before test code accumulates.
- Do NOT use when: the ask is a test plan for ONE feature or release — that is
  `test-plan-designer` (it instantiates this strategy).
- Do NOT use when: the ask is "what do our tests cover today" — that is
  `test-coverage-mapper` (audit, not strategy).
- Do NOT use when: the ask is to design the automation framework, tooling, or
  CI mechanics — that is `qa-automation-architect` (it implements this
  strategy's layer decisions).
- Do NOT use when: the ask is a whole-repo health audit — that is the shipped
  `full-codebase-auditor`; this skill governs testing, not general code health.

## Inputs to Inspect

1. What the product does and for whom: README, docs, routes/commands, the
   domain model if one exists (`domain-modeler` output).
2. Existing test reality: test directories, runners in use, CI workflow files,
   what currently gates a merge.
3. Risk sources: security-sensitive surfaces (auth, tenant boundaries,
   payments, exports), prior incidents/bug history, compliance obligations.
4. The change classes in use (`change-classification-gate` output if present)
   — the strategy maps each class to its validation floor (the minimum set
   of checks that class must pass).
5. Team/ownership signals: CODEOWNERS, who fixes broken tests today.

## Workflow

1. **Build the risk inventory first.** Enumerate failure modes that matter:
   data loss/corruption, cross-tenant leakage, broken auth, money errors,
   broken critical journeys, regressions in integrations. Rank by impact ×
   likelihood. No layer decisions before this exists — QA starts from risk.
2. **Assign each risk to the cheapest reliable layer.** Use the decision
   table in [references/risk-and-layer-catalog.md](references/risk-and-layer-catalog.md):
   pure logic → unit; boundary behavior (service/DB/auth) → integration;
   schema/shape compatibility → contract; critical user journeys (few) → E2E;
   visual/judgment checks → manual + screenshot evidence. A risk covered at
   a more expensive layer than necessary is a finding, not a virtue.
3. **Declare the layer split explicitly** — automation vs manual is a named
   decision per risk area, never an accident. Security negative testing
   (cross-tenant, authorization) is delegated to the shipped
   `multi-tenant-security-tester` *(manual-only)* and `rls-policy-auditor`, not re-owned here.
4. **Define environments and data posture per layer:** what runs against
   in-memory fakes, what needs a seeded database, what needs a deployed
   environment; where test data comes from (delegate design to
   `test-data-architect`).
5. **Define required evidence per change class** (see the reading key):
   which checks are blocking, which artifacts (reports, screenshots per
   `screenshot-evidence-planner`) must exist, and what "green" means for
   docs-only vs schema vs UI changes.
6. **Place the CI gates:** which layers run on PR, on merge, nightly; what is
   allowed to be non-blocking and why; flake policy pointer
   (`flaky-test-detective` *(manual-only)* owns diagnosis, `regression-suite-curator` owns
   suite membership). If merging automatically deploys, put every required
   release gate before merge; use post-merge checks to verify deployment.
7. **Name ownership and exit criteria:** who owns each layer, who fixes red,
   and the strategy's own review date.
8. **Teach any owner-facing tradeoff before asking.** If release risk or
   staffing requires an owner choice, define the test-layer and CI terms,
   explain why the choice matters, and compare viable options by money
   (including $0), setup time, ongoing execution/maintenance cost, coverage
   benefits and drawbacks, marking unpriced or unmeasured costs as unknown.
   Recommend the least costly reliable fit for the ranked risk, explain why,
   name the fact that would change it, then ask exactly one owner question.
   Choose routine test-layer assignments from evidence without asking the
   owner. Treat an already stated owner choice as settled and explain its
   implications without re-asking. The answer sets the strategy; it does not
   itself authorize staffing changes, new tools, or CI changes.

## Output Format

```
QA STRATEGY — <product/repo>
Risk inventory: <ranked risks, each with impact and likelihood rationale>
Layer decisions: <risk → layer → why this is the cheapest reliable layer>
Automation/manual split: <explicit, per risk area>
Environments & data: <per layer: env assumption + data source (test-data-architect)>
Evidence per change class: <class → blocking checks + required artifacts>
CI placement: <PR / merge / nightly per layer; non-blocking exceptions + why>
Ownership: <layer → owner; red-build policy>
Delegations: <security negatives → multi-tenant-security-tester / rls-policy-auditor;
             per-change plans → test-plan-designer; tooling → qa-automation-architect>
Exit criteria & review date: <when this strategy is met; when it is re-reviewed>
Owner choice brief (only if needed): <terms; why now; options with money,
  setup/run/maintenance costs or unknowns, pros and cons; recommendation,
  fit, and what would change it; one owner question>
```

## Validation Checklist

- [ ] Risk inventory exists and every layer decision traces to a named risk.
- [ ] Every layer choice states why a cheaper layer was insufficient.
- [ ] Automation/manual split is explicit per risk area.
- [ ] Environment assumptions and test-data source named per layer.
- [ ] Evidence requirements defined per change class, including artifacts.
- [ ] CI placement defined (PR/merge/nightly) with named non-blocking exceptions.
- [ ] Ownership and exit criteria stated; review date set.
- [ ] Security negative testing delegated, not duplicated.
- [ ] Any owner-facing choice explains terms, costs, pros and cons, and a
      reasoned recommendation before exactly one owner question.

## Gotchas

- A strategy written from the org chart ("we have QA engineers, so manual
  everything") instead of the risk inventory produces expensive, slow
  coverage — always derive layers from risks.
- Inverted pyramids (everything E2E) usually come from missing seams; flag the
  architectural cause, don't just prescribe "write more unit tests."
- "100% coverage" as a goal is a smell — coverage percentage is an input to
  `test-coverage-mapper`, not a strategy objective.
- Strategies that omit manual/judgment testing entirely leave visual, UX, and
  exploratory risks unowned — the split must be explicit even when the answer
  is "none, because X".
- A strategy nobody can violate is a strategy nobody follows: every rule needs
  a blocking check or a named owner.

## Stop Conditions

- The product's purpose or critical journeys cannot be determined from the
  repo and no one has described them → ask; a risk inventory cannot be
  invented.
- Risk ranking requires business context (revenue impact, compliance scope)
  that is not available → present the inventory with explicit assumptions and
  ask for ranking confirmation instead of guessing.
- The ask turns into implementing the strategy (writing tests, CI changes) →
  that is `qa-automation-architect` / the engineer skills; confirm scope
  before proceeding.

## Supporting Files

- [references/risk-and-layer-catalog.md](references/risk-and-layer-catalog.md) —
  risk taxonomy, the layer decision table, and evidence-class examples.
- `evals/evals.json` — trigger + behavior cases.
- `evals/trigger-evals.json` — discrimination within the strategy/plan/coverage
  cluster and against the shipped `full-codebase-auditor`.