QA Testing Strategy (Jan 2026)

現代的なソフトウェア配信のためのリスク駆動型品質エンジニアリング戦略。

コア参考資料: data/sources.json にキュレーションされたリンク (SLO / エラー予算、契約、E2E、OpenTelemetry)。references/operational-playbook.md から始めてコンパクトで便利な概要を確認してください。

スコープ

• リスク駆動型テスト戦略の作成または更新 (何をテストするか、どこで、なぜか)
• 品質ゲートとリリース基準の定義 (マージ対デプロイ)
• 最小限の有効なレイヤーの選択 (ユニット → 統合 → コントラクト → E2E)
• 障害を診断可能にする (アーティファクト、ログ/トレース、所有権)
• 信頼性の運用化 (フレーク SLO、隔離、スイート予算)

代わりに使用するスキル

必要な場合	スキル
テストまたはインシデントの失敗をデバッグ	qa-debugging
LLM エージェント / ペルソナをテスト	qa-agent-testing
セキュリティ監査 / 脅威モデルを実施	software-security-appsec
CI/CD パイプラインとインフラを設計	ops-devops-platform

クイックリファレンス

テストタイプ	目的	典型的な用途
Unit	ロジックと不変性を素早く証明	純粋関数、コアビジネスルール
Component	UI 動作を単体で検証	UI コンポーネントと状態遷移
Integration	実際の依存関係との境界を検証	API + DB、キュー、外部アダプタ
Contract	チーム間の破壊的変更を防止	OpenAPI / AsyncAPI / JSON Schema / Protobuf
E2E	クリティカルなユーザージャーニーを検証	製品エリアごとに 1～2 個の「マネーパス」
Performance	予算と容量を強制	ロード、ストレス、ソーク、回帰トレンド
Visual	UI 回帰をキャッチ	安定したページのレイアウト / ビジュアル差分
Accessibility	WCAG チェックを自動化	axe スモーク + ターゲットを絞った手動監査
Security	一般的な Web 脆弱性を早期にキャッチ	DAST スモーク + CI の重要チェック

デフォルトワークフロー

1. スコープとリスクを明確化：クリティカルなジャーニー、障害モード、非機能的リスク (レイテンシ、データ喪失、認証)。
2. 品質シグナルを定義：SLO / エラー予算、コントラクト / スキーマチェック、マージをブロックするもの対デプロイをブロックするもの。
3. 最小限の有効なレイヤーを選択 (ユニット → 統合 → コントラクト → E2E)。
4. 障害を診断可能にする：アーティファクト + 相関 ID (ログ / トレース / スクリーンショット)、明確な所有権、デフレーク実行ブック。
5. 運用化：フレーク SLO、満期付き隔離、スイート予算 (PR ゲート対スケジュール済み)、ダッシュボード。

テストピラミッド

           /\
          /E2E\          5-10% - クリティカルなジャーニー
         /------\
        /Integr. \       15-25% - API、DB、キュー
       /----------\
      /Component \       20-30% - UI モジュール
     /------------\
    /   Unit      \      40-60% - ロジックと不変性
   /--------------\

デシジョンツリー：テスト戦略

テスト対象：[機能タイプ]
    │
    ├─ 純粋なビジネスロジック / 不変性? → ユニットテスト (境界をモック)
    │
    ├─ UI コンポーネント / 状態遷移? → コンポーネントテスト
    │   └─ ページ間のユーザージャーニー? → E2E テスト
    │
    ├─ API エンドポイント?
    │   ├─ 単一サービス境界? → 統合テスト (実DB / 依存関係)
    │   └─ クロスサービス互換性? → コントラクトテスト (スキーマ / バージョニング)
    │
    ├─ イベント駆動 / API スキーマ進化? → コントラクト + 下位互換テスト
    │
    └─ パフォーマンスクリティカル? → k6 ロードテスト

コア QA 原則

完了の定義

• 戦略はリスク駆動型：クリティカルなジャーニー + 障害モードが明確
• テストポートフォリオが階層化：高速チェックが大部分の欠陥をキャッチ
• CI が効率的：高速なマージ前ゲート、重いスイートはスケジュール済み
• 障害が診断可能：実行可能なアーティファクト (ログ / トレース / スクリーンショット)
• フレークが SLO と デフレーク実行ブックで管理される

シフトレフトゲート (マージ前)

• コントラクト：OpenAPI / AsyncAPI / JSON Schema 検証
• 静的チェック：lint、型チェック、シークレットスキャン
• 高速テスト：ユニット + 重要な統合 (PR ゲートとして完全な E2E を避ける)

シフトライト (デプロイ後)

• クリティカルパスの合成チェック (モニタリング-as-テスト)
• カナリア分析：ランプ前の SLO シグナルと主要メトリクスを比較
• フィーチャーフラグで安全なロールアウトと高速ロールバック
• インシデントを回帰テストに変換 (下位レイヤー優先)

CI 経済学

予算	ターゲット
PR ゲート	p50 ≤ 10 分、p95 ≤ 20 分
メインライン健全性	≥ 99% グリーンビルド / 日

フレーク管理

• 定義：製品変更がないのにテストが失敗し、再実行で成功
• 週単位で追跡：flaky_failures / total_test_executions (flaky_failure = fail_then_pass_on_rerun の場合)
• SLO：スイートフレークレート ≤ 1% 週単位
• 所有者と満期を含む隔離ポリシー
• デフレーク実行ブックを使用：template-flaky-test-triage-deflake-runbook.md

一般的なパターン

AAA パターン

it('should apply discount', () => {
  // Arrange
  const order = { total: 150 };
  // Act
  const result = calculateDiscount(order);
  // Assert
  expect(result.discount).toBe(15);
});

ページオブジェクトモデル (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"]');
  }
}

アンチパターン

アンチパターン	問題	解決策
実装のテスト	リファクタで破損	動作をテスト
共有可変状態	フレーキなテスト	テストデータを分離
テスト内の sleep()	遅い、信頼性がない	適切な待機を使用
すべてが E2E	遅い、高コスト	テストピラミッドを使用
フレーキなテストを無視	誤った確信	修正または隔離

する / しない

する

• 安定したコントラクトとユーザー目視の動作に対してテストを記述
• フレーキなテストを P1 信頼性作業として扱う
• 「この障害をデバッグする方法」をすべてのスイートに含める

しない

• デフォルトとして「すべてが E2E」
• スリープ / 時間ベースの待機 (イベントベースを使用)
• カバレッジ% を主要品質 KPI として

機能マトリックス対テストマトリックスゲート (リリースブロッキング)

リリース前に、製品機能 / バックログ ID を直接テスト証拠にマッピングするカバレッジ監査を実行します。

ゲートルール

• すべてのリリーススコープ機能は、少なくとも 1 つの直接自動化テスト、または所有者 / 日付を持つ明示的な免除にマッピングする必要があります。
• 証拠には、ファイルパスとテスト識別子 (スイート / スペック / ケース) を含める必要があります。
• 「間接的にカバーされている」は、書面による根拠とリスク確認なしには受け入れられません。
• クリティカル機能に直接証拠がない場合、リリースはブロックされます。

最小限の監査出力

• 機能 / バックログ ID
• カバレッジステータス (direct、indirect、none)
• 証拠参照
• リスクレベル
• 所有者とギャップの期限

リソース

リソース	目的
comprehensive-testing-guide.md	レイヤー全体のエンドツーエンド実行ブック
operational-playbook.md	テストピラミッド、BDD、CI ゲート
shift-left-testing.md	コントラクトファースト、BDD、継続的テスト
test-automation-patterns.md	信頼性のあるパターンとアンチパターン
playwright-webapp-testing.md	Playwright パターン
chaos-resilience-testing.md	カオスエンジニアリング
observability-driven-testing.md	OpenTelemetry、トレースベース
contract-testing-2026.md	Pact、Specmatic
synthetic-test-data.md	プライバシーセーフで一時的なテストデータ
test-environment-management.md	環境プロビジョニングとライフサイクル
quality-metrics-dashboard.md	品質メトリクスとダッシュボード
compliance-testing.md	SOC2、HIPAA、GDPR、PCI-DSS テスト
feature-matrix-vs-test-matrix-gate.md	リリースブロッキング機能対テストカバレッジ監査

テンプレート

テンプレート	目的
template-test-case-design.md	Given / When / Then とテストオラクル
test-strategy-template.md	リスク駆動型戦略
template-flaky-test-triage.md	フレークトリアージ実行ブック
template-jest-vitest.md	ユニットテストパターン
template-api-integration.md	API + DB 統合テスト
template-playwright.md	Playwright E2E
template-visual-testing.md	ビジュアル回帰テスト
template-k6-load-testing.md	k6 パフォーマンス
automation-pipeline-template.md	CI ステージ、予算、ゲート
template-cucumber-gherkin.md	BDD フィーチャーファイルとステップ
template-release-coverage-audit.md	機能マトリックス対テストマトリックスリリース監査

データ

ファイル	目的
sources.json	外部参考資料

関連スキル

• qa-debugging — テスト失敗のデバッグ
• qa-agent-testing — AI エージェントのテスト
• software-backend — テストするべき API パターン
• ops-devops-platform — CI / CD パイプライン

Ops ゲート：リリースセーフ検証シーケンス

ユーザーフロー、価格設定、ローカライゼーション、またはアナリティクスに対して機能ブランチに使用するこのシーケンス。

# 1) 静的チェック
npm run lint
npm run typecheck

# 2) 高速正確性チェック
npm run test:unit

# 3) クリティカルパスチェック
npm run test:e2e -- --grep "@critical"

# 4) インストルメンテーションゲート (設定されている場合)
npm run test:analytics-gate

# 5) 本番ビルド
npm run build

ゲートが失敗した場合

1. 正確な失敗コマンドと最初のエラー行をキャプチャします。
2. 分類：環境の問題、既知の基準障害、または回帰。
3. 修正後、失敗したゲートのみを 1 回再実行します。
4. 前の必須ゲートが赤い間は、後のゲートに進みません。

QA ハンドオフのエージェント出力コントラクト

常に報告してください：

• 実行されたコマンド、
• ゲートごとのパス / 失敗、
• 障害が既存であるか導入されたかどうか、
• 次のブロッキング アクション。

ファクトチェック

• 最終回答の前に、Web 検索 / Web フェッチを使用して現在の外部事実、バージョン、価格、期限、規制、またはプラットフォーム動作を確認します。
• プライマリソースを優先します。揮発性情報のソースリンクと日付を報告します。
• Web アクセスが利用できない場合は、制限を説明し、ガイダンスを未検証としてマークします。