QA Testing Strategy (Jan 2026)

data/sources.json

references/operational-playbook.md

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

Default Workflow

1. Clarify scope and risk: critical journeys, failure modes, and non-functional risks (latency, data loss, auth).
2. Define quality signals: SLOs/error budgets, contract/schema checks, and what blocks merge vs blocks deploy.
3. Choose the smallest effective layer (unit → integration → contract → E2E).
4. Make failures diagnosable: artifacts + correlation IDs (logs/traces/screenshots), clear ownership, deflake runbook.
5. 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

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

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

Templates

Data

Related Skills

• qa-debugging — Debugging failing tests
• qa-agent-testing — Testing AI agents
• software-backend — API patterns to test
• ops-devops-platform — CI/CD pipelines