QA Testing Strategy (Jan 2026)
Risk-based quality engineering strategy for modern software delivery.
Core references: curated links in data/sources.json (SLOs/error budgets, contracts, E2E, OpenTelemetry). Start with references/operational-playbook.md for a compact, navigable overview.
Scope
- Create or update a risk-based test strategy (what to test, where, and why)
- Define quality gates and release criteria (merge vs deploy)
- Select the smallest effective layer (unit → integration → contract → E2E)
- Make failures diagnosable (artifacts, logs/traces, ownership)
- Operationalize reliability (flake SLO, quarantines, suite budgets)
Use Instead
Quick Reference
| Test Type |
Goal |
Typical Use |
| Unit |
Prove logic and invariants fast |
Pure functions, core business rules |
| Component |
Validate UI behavior in isolation |
UI components and state transitions |
| Integration |
Validate boundaries with real deps |
API + DB, queues, external adapters |
| Contract |
Prevent breaking changes cross-team |
OpenAPI/AsyncAPI/JSON Schema/Protobuf |
| E2E |
Validate critical user journeys |
1–2 “money paths” per product area |
| Performance |
Enforce budgets and capacity |
Load, stress, soak, regression trends |
| Visual |
Catch UI regressions |
Layout/visual diffs on stable pages |
| Accessibility |
Automate WCAG checks |
axe smoke + targeted manual audits |
| Security |
Catch common web vulns early |
DAST smoke + critical checks in CI |
Default Workflow
- Clarify scope and risk: critical journeys, failure modes, and non-functional risks (latency, data loss, auth).
- Define quality signals: SLOs/error budgets, contract/schema checks, and what blocks merge vs blocks deploy.
- Choose the smallest effective layer (unit → integration → contract → E2E).
- Make failures diagnosable: artifacts + correlation IDs (logs/traces/screenshots), clear ownership, deflake runbook.
- Operationalize: flake SLO, quarantine with expiry, suite budgets (PR gate vs scheduled), dashboards.
Test Pyramid
/\
/E2E\ 5-10% - Critical journeys
/------\
/Integr. \ 15-25% - API, DB, queues
/----------\
/Component \ 20-30% - UI modules
/------------\
/ Unit \ 40-60% - Logic and invariants
/--------------\
Decision Tree: Test Strategy
Need to test: [Feature Type]
│
├─ Pure business logic/invariants? → Unit tests (mock boundaries)
│
├─ UI component/state transitions? → Component tests
│ └─ Cross-page user journey? → E2E tests
│
├─ API Endpoint?
│ ├─ Single service boundary? → Integration tests (real DB/deps)
│ └─ Cross-service compatibility? → Contract tests (schema/versioning)
│
├─ Event-driven/API schema evolution? → Contract + backward-compat tests
│
└─ Performance-critical? → k6 load testing
Core QA Principles
Definition of Done
- Strategy is risk-based: critical journeys + failure modes explicit
- Test portfolio is layered: fast checks catch most defects
- CI is economical: fast pre-merge gates, heavy suites scheduled
- Failures are diagnosable: actionable artifacts (logs/trace/screenshots)
- Flakes managed with SLO and deflake runbook
Shift-Left Gates (Pre-Merge)
- Contracts: OpenAPI/AsyncAPI/JSON Schema validation
- Static checks: lint, typecheck, secret scanning
- Fast tests: unit + key integration (avoid full E2E as PR gate)
Shift-Right (Post-Deploy)
- Synthetic checks for critical paths (monitoring-as-tests)
- Canary analysis: compare SLO signals and key metrics before ramping
- Feature flags for safe rollouts and fast rollback
- Convert incidents into regression tests (prefer lower layers first)
CI Economics
| Budget |
Target |
| PR gate |
p50 ≤ 10 min, p95 ≤ 20 min |
| Mainline health |
≥ 99% green builds/day |
Flake Management
- Define: test fails without product change, passes on rerun
- Track weekly:
flaky_failures / total_test_executions (where flaky_failure = fail_then_pass_on_rerun)
- SLO: Suite flake rate ≤ 1% weekly
- Quarantine policy with owner and expiry
- Use the deflake runbook: template-flaky-test-triage-deflake-runbook.md
Common Patterns
AAA Pattern
it('should apply discount', () => {
// Arrange
const order = { total: 150 };
// Act
const result = calculateDiscount(order);
// Assert
expect(result.discount).toBe(15);
});
Page Object Model (E2E)
class LoginPage {
async login(email: string, password: string) {
await this.page.fill('[data-testid="email"]', email);
await this.page.fill('[data-testid="password"]', password);
await this.page.click('[data-testid="submit"]');
}
}
Anti-Patterns
| Anti-Pattern |
Problem |
Solution |
| Testing implementation |
Breaks on refactor |
Test behavior |
| Shared mutable state |
Flaky tests |
Isolate test data |
| sleep() in tests |
Slow, unreliable |
Use proper waits |
| Everything E2E |
Slow, expensive |
Use test pyramid |
| Ignoring flaky tests |
False confidence |
Fix or quarantine |
Do / Avoid
Do
- Write tests against stable contracts and user-visible behavior
- Treat flaky tests as P1 reliability work
- Make "how to debug this failure" part of every suite
Avoid
- "Everything E2E" as default
- Sleeps/time-based waits (use event-based)
- Coverage % as primary quality KPI
Resources
| Resource |
Purpose |
| comprehensive-testing-guide.md |
End-to-end playbook across layers |
| operational-playbook.md |
Testing pyramid, BDD, CI gates |
| shift-left-testing.md |
Contract-first, BDD, continuous testing |
| test-automation-patterns.md |
Reliable patterns and anti-patterns |
| playwright-webapp-testing.md |
Playwright patterns |
| chaos-resilience-testing.md |
Chaos engineering |
| observability-driven-testing.md |
OpenTelemetry, trace-based |
| contract-testing-2026.md |
Pact, Specmatic |
| synthetic-test-data.md |
Privacy-safe, ephemeral test data |
Templates
| Template |
Purpose |
| template-test-case-design.md |
Given/When/Then and test oracles |
| test-strategy-template.md |
Risk-based strategy |
| template-flaky-test-triage.md |
Flake triage runbook |
| template-jest-vitest.md |
Unit test patterns |
| template-api-integration.md |
API + DB integration tests |
| template-playwright.md |
Playwright E2E |
| template-visual-testing.md |
Visual regression testing |
| template-k6-load-testing.md |
k6 performance |
| automation-pipeline-template.md |
CI stages, budgets, gates |
| template-cucumber-gherkin.md |
BDD feature files and steps |
Data
| File |
Purpose |
| sources.json |
External references |
Related Skills
1---2name: qa-testing-strategy3description: Risk-based quality engineering test strategy for software delivery. Use when defining or updating test strategy, selecting unit/integration/contract/E2E/performance/security coverage, setting CI quality gates and suite budgets, managing flaky tests and test data, and operationalizing observability-first debugging and release criteria.4---5
6# QA Testing Strategy (Jan 2026)
7
8Risk-based quality engineering strategy for modern software delivery.
9
10**Core references**: curated links in `data/sources.json` (SLOs/error budgets, contracts, E2E, OpenTelemetry). Start with `references/operational-playbook.md` for a compact, navigable overview.
11
12## Scope
13
14- Create or update a risk-based test strategy (what to test, where, and why)
15- Define quality gates and release criteria (merge vs deploy)
16- Select the smallest effective layer (unit → integration → contract → E2E)
17- Make failures diagnosable (artifacts, logs/traces, ownership)
18- Operationalize reliability (flake SLO, quarantines, suite budgets)
19
20## Use Instead
21
22| Need | Skill |
23|------|-------|
24| Debug failing tests or incidents | [qa-debugging](../qa-debugging/SKILL.md) |
25| Test LLM agents/personas | [qa-agent-testing](../qa-agent-testing/SKILL.md) |
26| Perform security audit/threat model | [software-security-appsec](../software-security-appsec/SKILL.md) |
27| Design CI/CD pipelines and infra | [ops-devops-platform](../ops-devops-platform/SKILL.md) |
28
29## Quick Reference
30
31| Test Type | Goal | Typical Use |
32|-----------|------|-------------|
33| Unit | Prove logic and invariants fast | Pure functions, core business rules |
34| Component | Validate UI behavior in isolation | UI components and state transitions |
35| Integration | Validate boundaries with real deps | API + DB, queues, external adapters |
36| Contract | Prevent breaking changes cross-team | OpenAPI/AsyncAPI/JSON Schema/Protobuf |
37| E2E | Validate critical user journeys | 1–2 “money paths” per product area |
38| Performance | Enforce budgets and capacity | Load, stress, soak, regression trends |
39| Visual | Catch UI regressions | Layout/visual diffs on stable pages |
40| Accessibility | Automate WCAG checks | axe smoke + targeted manual audits |
41| Security | Catch common web vulns early | DAST smoke + critical checks in CI |
42
43## Default Workflow
44
451. Clarify scope and risk: critical journeys, failure modes, and non-functional risks (latency, data loss, auth).
462. Define quality signals: SLOs/error budgets, contract/schema checks, and what blocks merge vs blocks deploy.
473. Choose the smallest effective layer (unit → integration → contract → E2E).
484. Make failures diagnosable: artifacts + correlation IDs (logs/traces/screenshots), clear ownership, deflake runbook.
495. Operationalize: flake SLO, quarantine with expiry, suite budgets (PR gate vs scheduled), dashboards.
50
51## Test Pyramid
52
53```text
54 /\
55 /E2E\ 5-10% - Critical journeys
56 /------\
57 /Integr. \ 15-25% - API, DB, queues
58 /----------\
59 /Component \ 20-30% - UI modules
60 /------------\
61 / Unit \ 40-60% - Logic and invariants
62 /--------------\
63```
64
65## Decision Tree: Test Strategy
66
67```text
68Need to test: [Feature Type]
69 │
70 ├─ Pure business logic/invariants? → Unit tests (mock boundaries)
71 │
72 ├─ UI component/state transitions? → Component tests
73 │ └─ Cross-page user journey? → E2E tests
74 │
75 ├─ API Endpoint?
76 │ ├─ Single service boundary? → Integration tests (real DB/deps)
77 │ └─ Cross-service compatibility? → Contract tests (schema/versioning)
78 │
79 ├─ Event-driven/API schema evolution? → Contract + backward-compat tests
80 │
81 └─ Performance-critical? → k6 load testing
82```
83
84## Core QA Principles
85
86### Definition of Done
87
88- Strategy is risk-based: critical journeys + failure modes explicit
89- Test portfolio is layered: fast checks catch most defects
90- CI is economical: fast pre-merge gates, heavy suites scheduled
91- Failures are diagnosable: actionable artifacts (logs/trace/screenshots)
92- Flakes managed with SLO and deflake runbook
93
94### Shift-Left Gates (Pre-Merge)
95
96- Contracts: OpenAPI/AsyncAPI/JSON Schema validation
97- Static checks: lint, typecheck, secret scanning
98- Fast tests: unit + key integration (avoid full E2E as PR gate)
99
100### Shift-Right (Post-Deploy)
101
102- Synthetic checks for critical paths (monitoring-as-tests)
103- Canary analysis: compare SLO signals and key metrics before ramping
104- Feature flags for safe rollouts and fast rollback
105- Convert incidents into regression tests (prefer lower layers first)
106
107### CI Economics
108
109| Budget | Target |
110|--------|--------|
111| PR gate | p50 ≤ 10 min, p95 ≤ 20 min |
112| Mainline health | ≥ 99% green builds/day |
113
114### Flake Management
115
116- Define: test fails without product change, passes on rerun
117- Track weekly: `flaky_failures / total_test_executions` (where `flaky_failure = fail_then_pass_on_rerun`)
118- SLO: Suite flake rate ≤ 1% weekly
119- Quarantine policy with owner and expiry
120- Use the deflake runbook: [template-flaky-test-triage-deflake-runbook.md](assets/runbooks/template-flaky-test-triage-deflake-runbook.md)
121
122## Common Patterns
123
124### AAA Pattern
125
126```javascript
127it('should apply discount', () => {
128 // Arrange
129 const order = { total: 150 };
130 // Act
131 const result = calculateDiscount(order);
132 // Assert
133 expect(result.discount).toBe(15);
134});
135```
136
137### Page Object Model (E2E)
138
139```typescript
140class LoginPage {
141 async login(email: string, password: string) {
142 await this.page.fill('[data-testid="email"]', email);
143 await this.page.fill('[data-testid="password"]', password);
144 await this.page.click('[data-testid="submit"]');
145 }
146}
147```
148
149## Anti-Patterns
150
151| Anti-Pattern | Problem | Solution |
152|--------------|---------|----------|
153| Testing implementation | Breaks on refactor | Test behavior |
154| Shared mutable state | Flaky tests | Isolate test data |
155| sleep() in tests | Slow, unreliable | Use proper waits |
156| Everything E2E | Slow, expensive | Use test pyramid |
157| Ignoring flaky tests | False confidence | Fix or quarantine |
158
159## Do / Avoid
160
161### Do
162
163- Write tests against stable contracts and user-visible behavior
164- Treat flaky tests as P1 reliability work
165- Make "how to debug this failure" part of every suite
166
167### Avoid
168
169- "Everything E2E" as default
170- Sleeps/time-based waits (use event-based)
171- Coverage % as primary quality KPI
172
173## Resources
174
175| Resource | Purpose |
176|----------|---------|
177| [comprehensive-testing-guide.md](references/comprehensive-testing-guide.md) | End-to-end playbook across layers |
178| [operational-playbook.md](references/operational-playbook.md) | Testing pyramid, BDD, CI gates |
179| [shift-left-testing.md](references/shift-left-testing.md) | Contract-first, BDD, continuous testing |
180| [test-automation-patterns.md](references/test-automation-patterns.md) | Reliable patterns and anti-patterns |
181| [playwright-webapp-testing.md](references/playwright-webapp-testing.md) | Playwright patterns |
182| [chaos-resilience-testing.md](references/chaos-resilience-testing.md) | Chaos engineering |
183| [observability-driven-testing.md](references/observability-driven-testing.md) | OpenTelemetry, trace-based |
184| [contract-testing-2026.md](references/contract-testing-2026.md) | Pact, Specmatic |
185| [synthetic-test-data.md](references/synthetic-test-data.md) | Privacy-safe, ephemeral test data |
186
187## Templates
188
189| Template | Purpose |
190|----------|---------|
191| [template-test-case-design.md](assets/template-test-case-design.md) | Given/When/Then and test oracles |
192| [test-strategy-template.md](assets/test-strategy-template.md) | Risk-based strategy |
193| [template-flaky-test-triage.md](assets/runbooks/template-flaky-test-triage-deflake-runbook.md) | Flake triage runbook |
194| [template-jest-vitest.md](assets/unit/template-jest-vitest.md) | Unit test patterns |
195| [template-api-integration.md](assets/integration/template-api-integration.md) | API + DB integration tests |
196| [template-playwright.md](assets/e2e/template-playwright.md) | Playwright E2E |
197| [template-visual-testing.md](assets/visual-regression/template-visual-testing.md) | Visual regression testing |
198| [template-k6-load-testing.md](assets/performance/template-k6-load-testing.md) | k6 performance |
199| [automation-pipeline-template.md](assets/automation-pipeline-template.md) | CI stages, budgets, gates |
200| [template-cucumber-gherkin.md](assets/bdd/template-cucumber-gherkin.md) | BDD feature files and steps |
201
202## Data
203
204| File | Purpose |
205|------|---------|
206| [sources.json](data/sources.json) | External references |
207
208## Related Skills
209
210- [qa-debugging](../qa-debugging/SKILL.md) — Debugging failing tests
211- [qa-agent-testing](../qa-agent-testing/SKILL.md) — Testing AI agents
212- [software-backend](../software-backend/SKILL.md) — API patterns to test
213- [ops-devops-platform](../ops-devops-platform/SKILL.md) — CI/CD pipelines