Agent Skills: QA Testing Strategy (Jan 2026)

Risk-based test strategy for software delivery. Use when defining coverage, setting CI gates, managing flaky tests, or establishing release criteria.

UncategorizedID: vasilyu1983/ai-agents-public/qa-testing-strategy

Install this agent skill to your local

pnpm dlx add-skill https://github.com/vasilyu1983/AI-Agents-public/tree/HEAD/frameworks/shared-skills/skills/qa-testing-strategy

Skill Files

Browse the full folder contents for qa-testing-strategy.

Download Skill

Loading file tree…

frameworks/shared-skills/skills/qa-testing-strategy/SKILL.md

Skill Metadata

Name
qa-testing-strategy
Description
Risk-based test strategy for software delivery. Use when defining coverage, setting CI gates, managing flaky tests, or establishing release criteria.

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

| Need | Skill | |------|-------| | Debug failing tests or incidents | qa-debugging | | Test LLM agents/personas | qa-agent-testing | | Perform security audit/threat model | software-security-appsec | | Design CI/CD pipelines and infra | ops-devops-platform |

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

  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

| 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

Feature Matrix vs Test Matrix Gate (Release Blocking)

Before release, run a coverage audit that maps product features/backlog IDs to direct test evidence.

Gate Rules

  • Every release-scoped feature must map to at least one direct automated test, or an explicit waiver with owner/date.
  • Evidence must include file path and test identifier (suite/spec/case).
  • "Covered indirectly" is not accepted without written rationale and risk acknowledgment.
  • If critical features have no direct evidence, release is blocked.

Minimal Audit Output

  • feature/backlog id
  • coverage status (direct, indirect, none)
  • evidence reference
  • risk level
  • owner and due date for gaps

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 | | test-environment-management.md | Environment provisioning and lifecycle | | quality-metrics-dashboard.md | Quality metrics and dashboards | | compliance-testing.md | SOC2, HIPAA, GDPR, PCI-DSS testing | | feature-matrix-vs-test-matrix-gate.md | Release-blocking feature-to-test coverage audit |

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 | | template-release-coverage-audit.md | Feature matrix vs test matrix release audit |

Data

| File | Purpose | |------|---------| | sources.json | External references |

Related Skills

Ops Gate: Release-Safe Verification Sequence

Use this sequence for feature branches that touch user flows, pricing, localization, or analytics.

# 1) Static checks
npm run lint
npm run typecheck

# 2) Fast correctness
npm run test:unit

# 3) Critical path checks
npm run test:e2e -- --grep "@critical"

# 4) Instrumentation gate (if configured)
npm run test:analytics-gate

# 5) Production build
npm run build

If a Gate Fails

  1. Capture exact failing command and first error line.
  2. Classify: environment issue, baseline known failure, or regression.
  3. Re-run only the failed gate once after fix.
  4. Do not continue to later gates while earlier required gates are red.

Agent Output Contract for QA Handoff

Always report:

  • commands run,
  • pass/fail per gate,
  • whether failures are pre-existing or introduced,
  • next blocking action.

Fact-Checking

  • Use web search/web fetch to verify current external facts, versions, pricing, deadlines, regulations, or platform behavior before final answers.
  • Prefer primary sources; report source links and dates for volatile information.
  • If web access is unavailable, state the limitation and mark guidance as unverified.