qa-testing-strategy

QA テスト戦略

最新のソフトウェア開発に向けた、リスクベースの品質エンジニアリングガイダンスです。何をどのレイヤーでテストするか、どのゲートを設けるか、そして信頼できるシグナルを維持する方法を判断するために、このスキルを使用してください。

ナビゲーションハブとして、まず references/operational-playbook.md を参照してください。ベンダーや標準に関するガイダンスが必要な場合は、data/sources.json にある最新の公式情報を使用してください。

対象範囲

• リスクベースのテスト戦略を作成または更新する
• アーキテクチャと欠陥の発生源に基づいて、テスト構成（ピラミッド、トロフィー、ハニカム）を選択する
• マージキューとの連携を含め、マージゲート、デプロイゲート、リリースの証跡を定義する
• 最小限で効果的なレイヤーを選択する：ユニット、コンポーネント、コントラクト、スキーマファジング、統合、E2E、プロパティベース
• 成果物、相関 ID、トレース、担当者によって、失敗を診断可能にする
• スイートの健全性を運用に組み込む：フレーク SLO、隔離ポリシー、実行予算、ダッシュボード

代わりに使用

必要なこと	スキル
Playwright スイートを実装またはデバッグする	qa-testing-playwright
API コントラクトスイートを詳しく設計する	qa-api-testing-contracts
失敗するテストやインシデントをデバッグする	qa-debugging
オブザーバビリティ、テレメトリー、トレーシングを追加する	qa-observability
LLM エージェントや評価をテストする	qa-agent-testing
モバイル固有の戦略や自動化	qa-testing-mobile
セキュリティ監査や脅威モデリングを詳しく行う	software-security-appsec
CI/CD パイプライン設計とインフラ	ops-devops-platform

クイックリファレンス

レイヤー	目標	典型的な用途
ユニット	ロジックと不変条件を素早く検証する	純粋関数、ドメインルール、バリデーター
コンポーネント	実際のブラウザーで、対象を絞って UI の動作を検証する	UI コンポーネント、状態遷移、アクセシビリティのスモークテスト
コントラクト	サービス境界をまたぐ破壊的変更を防ぐ	OpenAPI、AsyncAPI、JSON Schema、Protobuf
スキーマファジング	生成した有効・無効な入力で API コントラクトに負荷をかける	リクエスト／レスポンスの境界ケース、パーサーやバリデーションの乖離
プロパティベース	生成された入力空間全体で普遍的な不変条件を検証する	シリアライゼーションの往復、数値コントラクト、状態機械の不変条件、AI コードのエッジケース
統合	実際の境界と依存関係を検証する	API と DB、キュー、アダプター、認証フロー
E2E	重要なジャーニーを絞って検証する	サインアップ、チェックアウト、公開、決済、管理者による復旧
パフォーマンス	予算と処理能力を維持する	負荷、ストレス、長時間稼働、レイテンシのリグレッション
ビジュアル	意図的な UI 変更と意図しない UI 変更を検出する	安定したページ、デザインシステムのコンポーネント
アクセシビリティ	よくある WCAG 2.2 違反を早期に確認する	axe スモークテストと手動監査計画
セキュリティ	よくある Web／API の脆弱性を早期に検出する	SAST、DAST スモークテスト、認証と依存関係のチェック

E2E ゲートの構成（デフォルト）

1 つの巨大なスイートにまとめるのではなく、3 つの異なる E2E スコープを使用します。

• スモーク：PR ゲート。最もリスクの高いジャーニーについて、最も速くフィードバックを得ます。
• 対象を絞ったバッチ／スペック：1 つのジャーニー、サブシステム、依存関係チェーンを対象に、ローカルでトリアージとフレーク解消を行います。
• デプロイゲートの再実行：リリース準備の証明に限って使用する、依存関係チェーンまたは重要なジャーニーの再実行です。

ルール：

• 1 つのジャーニーが失敗した際、最初の対応としてローカルで E2E 全体を実行しないでください。
• 再実行で成功した場合も、フレークの未解決負債として扱ってください。
• より小さなスコープが成功してから、スコープを広げてください。

デフォルトのワークフロー

1. 範囲とリスクを明確にします。重要なユーザージャーニー、障害モード、コンプライアンス上の制約、非機能リスクを確認します。
2. 品質シグナルを定義します。SLO、予算、コントラクトチェック、アクセシビリティの目標、マージとデプロイのどちらをブロックするかを定めます。
3. それぞれの重要なリスクを、主張、オラクル、レイヤー、環境、ビルドの識別情報、証拠となる成果物、担当者、有効期限に対応付けます。configured、executed、behavior-verified、release-observedのいずれかのラベルを付けます。静的解析、検出、カバレッジ、グリーンビルドは、実行された振る舞いの検証には達しません。
4. まず最小限で効果的なレイヤーを選びます。ユニット、コンポーネント、コントラクト、スキーマファジング、統合、E2Eの順です。
5. 失敗を診断できるようにします。ログ、トレース、スクリーンショット、動画、ビルドへのリンク、リクエスト ID、トレース ID、担当者を記録します。
6. テストスイートを運用可能な状態にします。スモーク、対象を絞ったバッチ、デプロイゲートの範囲を明示し、有効期限付きで隔離し、スイートの予算を設け、証拠を保持した再試行とダッシュボードを用意します。対象を絞ったテストの合格をリリース全体の証明として扱わず、未対応の重要リスクと次のゲートを列挙します。

判断ルール

Need to test: [Change or Risk]
    │
    ├─ Pure business rule or invariant?
    │   └─ Unit test
    │
    ├─ UI behavior or component state in isolation?
    │   └─ Component test in a real browser
    │
    ├─ API compatibility between teams/services?
    │   └─ Contract test
    │
    ├─ API parser/validation edge cases against the schema?
    │   └─ Schema-aware fuzzing + core integration smoke
    │
    ├─ Real dependency boundary or persistence behavior?
    │   └─ Integration test with real DB/queue/service doubles only at external edges
    │
    ├─ User-critical cross-page workflow?
    │   └─ Thin E2E test
    │
    ├─ Universal invariant or property that should hold for all valid inputs?
    │   └─ Property-based test (fast-check / Hypothesis / jqwik)
    │
    └─ Capacity, resilience, or reliability regression?
        └─ Performance, resilience, or synthetic monitoring tests

リスクベースの優先順位付け

カバレッジは形状ではなくリスクに応じて割り当てます。テストを選ぶ前に各ユーザージャーニーまたはモジュールを採点し、そのスコアを戦略の1ページ資料に記載します。

• 影響度（1～3）：収益、データ損失、セキュリティまたはコンプライアンス上のリスク、顧客への連絡なしに障害から復旧できるかどうか。
• 発生可能性（1～3）：直近の四半期における変更頻度、リリース後に発覚した不具合の履歴、通過する統合境界の数、AI が作成したコードまたは新規コントリビューターのコードの割合。
• リスク ＝ 影響度 × 発生可能性。スコアが 6 以上の場合は、複数レイヤーで実行された振る舞いの証拠を取得し、デプロイゲートでチェックします。3～5 の場合は、主張を証明できる最小限の単一レイヤーを選びます。2 以下の場合は、静的チェックと機会に応じたユニットテストのみとし、そのギャップを戦略に明記します。
• インシデント発生後と各四半期に再採点します。スコアが下がったモジュールは、ほかの場所でテストが増える前に PR ゲートからテストを減らします。

コントラクトテストと E2E

• コントラクトテストは、1 つの境界で 2 つの当事者が形式と意味に合意していることを証明します。E2E は、デプロイ済みビルドで複数の境界にまたがるユーザージャーニーが機能することを証明します。互いの代わりにはなりません。
• デフォルトでは、デプロイの頻度が異なるサービス境界ごとにマージ前のコントラクトチェックを行い、収益またはデータ損失に関わるユーザージャーニーごとに、デプロイゲートで薄い E2E テストを 1 つ実行します。それ以外には、デフォルトで E2E を適用しません。
• 前四半期に検出した障害が境界の形式不一致または永続化のバグであれば、E2E をコントラクトテストと統合テストに置き換えます。サービス間の処理順序、認証セッションのフロー、または下位レイヤーでは確認できない UI の状態に起因する障害であれば、E2E を維持します。
• コンシューマー側の検証がないコントラクトテスト（プロバイダーがスキーマを公開しても、コンシューマーとの照合が行われない場合）は、証拠ではなくドキュメントです。

カバレッジ指標

• 行カバレッジと分岐カバレッジが測定するのは実行であり、アサーションではありません。PR でカバレッジが低下しないことを確認するゲートと、未テストのファイルを見つける目的に限って使用し、リリース基準にはしないでください。
• 差分レベルのゲートを超えるカバレッジ数値は、実行するだけでアサーションを行わないテストによって操作される目標になります。数値が重要な領域（認証、支払い、マイグレーション、ドメインルール）では、代わりに変更ファイルのミューテーションスコアをゲートにします。ポリシーについてはreferences/quality-metrics-dashboard.mdを参照してください。
• テスト影響分析または部分的なテストスイートで取得したカバレッジは、フルスイートのベースラインとは比較できません。同じ条件で比較しないと、差分ゲートがノイズで作動します。
• チェック対象の各コンポーネントについて、少なくとも 1 つのチェックで、上書きやパッチを適用したコピーを使わずに、出荷時のデフォルト（設定、同梱データ、エントリーポイント）を実行します。独自のフィクスチャを構築またはパッチするテストが証明するのは、そのフィクスチャだけです。不自然なほど簡単に通るチェックは、結果を信頼する前に観測方法を調べるべき兆候です。

不安定なテストのポリシー

• テストに手を加える前に、分類体系に従って分類します。環境に起因する失敗は環境側で修正し、隔離してはいけません。
• 隔離する場合は、担当者、チケット、有効期限を設定し、範囲を最小限（ファイル単位ではなく、テスト1件）にします。隔離中のテストも実行とレポートを継続します。有効期限が切れた隔離があると、ビルドは失敗します。
• 再実行での成功は、そのテストの不安定性負債として記録します。セキュリティ、認証、決済のテストは、成功するまで再試行してはいけません。
• 修正までの時間は、MTTR-Flake SLOの重大度区分に従います。特定のテストを当日中に隔離すべきかどうかは、運用プレイブックのマージキューコストモデルで判断します。

テストデータ

• 各テストは、一意の識別子を持つファクトリーを使って独自のデータを作成します。共有フィクスチャや、テストが変更するシード行は、実行順序に依存する不安定なテストの主な原因です。
• 実際の顧客データを CI、プレビュー、ステージングで使用してはいけません。本番環境に近いデータが必要な場合は、参照整合性を保ち、マスキングルールの担当者を定めたうえで、復元不能な方法でマスキングしたサブセットを使用します。references/synthetic-test-data.mdを参照してください。
• テスト実行ごとに固定のシード値を使ってデータ生成器を初期化し、失敗時にその値を出力して、ケースを再現できるようにします。

原則

• 挙動を証明できる最小のレイヤーを優先します。
• マージ前のゲートは高速に保ちます。契約、静的チェック、単体テスト、対象を絞ったコンポーネント／統合のスモークテストを実施します。
• ローカルでは対象を絞ったバッチ再実行を優先し、フル E2E はデプロイゲートまたは定期的な回帰テストに限定します。
• フル E2E は、重要なユーザージャーニーや、スタックの下位レイヤーでは証明できないリスクにのみ使用します。
• カスタム待機や脆弱なセレクターよりも、Web ファーストのアサーションと安定したロケーターを優先します。
• アクセシビリティの自動化は、網羅性が限定的であるものとして扱います。手動チェックとインクルーシブデザインのレビューを組み合わせます。
• テレメトリーを証拠として扱います。本番環境のトレース、インシデント、サポートの兆候をもとに、新しいテストを追加します。
• 証拠を紐付けたままにできる場合に限り、ブレインストーミングとトリアージに AI を使用します。テストを「修復」するためにアサーションを弱めてはいけません。
• AI が作成したテストのオラクル品質は、不安定性負債と同等の重要度を持つ主要なリスクとして扱います。AI 生成テストは、カバレッジが高くても、単純に成功してしまうことがよくあります（戻り値のハードコード、浅いアサーションなど）。テストを受け入れる前に、手間のかからない事前確認として、テスト対象のすべての関数が何も返さなくてもテストが成功するかを確認します。モックだけを使ったチェック、何も存在しないことだけを確認するチェック、自己参照的な期待値、固定された定数、自分自身を検証するフィクスチャは却下します。そのうえで、運用上のチェックではカバレッジではなくミューテーションスコアをゲートにします。ビジネスロジックを元に戻しても失敗しないテストは、テストではありません。
• 同じモデルが変更の作成とレビューを行う場合、レビューにも作成者と同じ盲点が生じます。AI にレビューさせる前にテストとビルドを実行し、まず失敗を報告します。次に、AI による変更で回帰が起こりやすい箇所に回帰テストを追加します。たとえば、片方のコードパスにはフィールドが追加されても、対応するもう一方には追加されていない場合（サンドボックスまたはモックモード、フラグ分岐、キャッシュまたはバッチパス）、クエリのプロジェクションやマッパーからレスポンスフィールドが欠落している場合、エラーを設定しても画面に古いデータが残るエラーハンドリング、呼び出し失敗時のロールバックがない楽観的更新などです。修正した各バグには、修正前のリビジョンで失敗するテストを用意します。

主な目標

指標	既定の目標
PR ゲート	p50 <= 10 min、p95 <= 20 min
メインラインの健全性	1 日あたりのビルド成功率 >= 99%
テストスイートの不安定率	週次で <= 1%
隔離ポリシー	担当者 + チケット + 有効期限を必須とし、無期限は禁止
AI 作成テストのオラクル品質	変更ファイルでミューテーションスコアをゲートにする（行カバレッジはゲートにしない）。しきい値はテストスイートに合わせて調整し、カバレッジだけを根拠に AI テストを受け入れない

リソース

• references/operational-playbook.md：まずはこちらをご覧ください
• references/component-testing-browser-mode.md：Vitest Browser Mode を使った、実ブラウザーでのコンポーネントテスト戦略
• references/playwright-webapp-testing.md：リダイレクト用スタブ — qa-testing-playwright をご覧ください
• references/schema-aware-api-fuzzing.md：OpenAPI を使ったスキーマ駆動の API ファジング
• qa-api-testing-contracts：コントラクトテスト（Pact、Specmatic、can-i-deploy、破壊的変更のゲート）の担当
• references/observability-driven-testing.md：OpenTelemetry を優先したデバッグとトレースベースの検証
• references/quality-metrics-dashboard.md：メトリクス、ダッシュボード、リリース準備状況のハードゲート、ミューテーションカバレッジのゲートポリシー
• references/production-testing-and-shift-right.md：合成モニタリング、ダークローンチ、フィーチャーフラグの段階的展開、MTTR とフレークの SLO、本番リプレイ、オブザーバビリティ駆動のゲート
• references/test-impact-analysis.md：TIA の概念、CloudBees Smart Tests（旧 Launchable）、Datadog Test Optimization、BuildPulse によるフレークの傾向分析、jest --findRelatedTests
• references/shift-left-testing.md：シフトレフトの実践、テストダブル、品質チェックを前倒しするカバレッジ目標
• references/test-automation-patterns.md：Page Object Model、データファクトリー、フィクスチャ、テストダブル、AAA、分離のパターン
• references/test-environment-management.md：環境のコード化、シーディング、サービス仮想化、分離、共有環境と専用環境のトレードオフ
• references/synthetic-test-data.md：テストデータ管理のルール — テストごとのファクトリー、マスキング済み本番データサブセット、シーディング、合成データが誤解を招く場合
• references/chaos-resilience-testing.md：qa-resilience へのリダイレクト用スタブ
• references/compliance-testing.md：コンプライアンスのコード化、監査証跡の自動化、アクセス制御、データレジデンシー、暗号化の検証（HIPAA のペネトレーションテスト規則は提案段階であり、確定していません）
• references/feature-matrix-vs-test-matrix-gate.md：実装済み機能と監査可能なテスト証跡を対応付けるリリース前ゲート
• references/property-based-testing.md：有効なドメインとオラクルを選び、fast-check、Hypothesis、jqwik（メンテナンスモードに関する注意事項あり）、またはポータブルなコントラクトランナーでプロパティテストとメタモルフィックテストを実行します
• references/comprehensive-testing-guide.md：各テストレイヤーを専用の関連スキルに案内する、廃止済みのリダイレクトマップ
• references/reliability-theory-applied.md：信頼性の基本要素（MTBF／MTTR、エラーバジェット、障害流出確率、最小カットセット）を QA テスト戦略に適用します
• scripts/release_readiness.py：リリース準備状況のゲート — 重み付けスコアの算出前に、ハードゲート（セキュリティ、重要な E2E、未解決の P0）を評価します。scripts/test_release_readiness.py をご覧ください

テンプレート

• assets/test-strategy-template.md：戦略の概要
• assets/automation-pipeline-template.md：CI/CD パイプラインの設計図
• assets/component/template-vitest-browser.md：ブラウザモードのコンポーネントテスト
• assets/e2e/template-playwright.md：リダイレクト用スタブ — 実際に使える Playwright テンプレートについては qa-testing-playwright を参照してください
• assets/bdd/template-cucumber-gherkin.md：重要なユーザージャーニーが Gherkin／BDD シナリオとして定義されている場合に使用します（references/operational-playbook.md を参照してください）
• assets/unit/template-jest-vitest.md：最小かつ効果的なレイヤーが Jest／Vitest の単体テストである場合に使用します（references/operational-playbook.md を参照してください）
• assets/integration/template-api-integration.md：API と DB の統合テスト
• assets/performance/template-k6-load-testing.md：リダイレクト用スタブ — 実際に使える k6 テンプレートについては qa-testing-performance を参照してください
• assets/visual-regression/template-visual-testing.md：リダイレクト用スタブ — ビジュアルリグレッションについては qa-testing-playwright を参照してください。安定したページのみを対象とする戦略ルールを維持します
• assets/runbooks/template-flaky-test-triage-deflake-runbook.md：不安定なテストを解消するためのランブック
• assets/runbooks/template-release-coverage-audit.md：references/feature-matrix-vs-test-matrix-gate.md の機能マトリックスとテストマトリックスによるリリースゲートを実行する場合に使用します
• assets/template-test-case-design.md：Given／When／Then とオラクル

プロパティベースおよびメタモルフィック契約ツール

• scripts/property_contract_runner.py：依存関係不要のアダプターランナー。決定論的なシードとケースインデックスによる再実行に対応しています
• assets/property_contract_example.py：意図的なネガティブコントロールの変更を含む、正しい動作が既知の計算機、設定パーサー、JSON ラウンドトリップのアダプター
• scripts/test_property_contract_runner.py：正しい動作、変更の検出、終了コード、再実行を検証します

このスキルディレクトリから、python3 scripts/property_contract_runner.py --contract assets/property_contract_example.py --seed 20260908 --cases 120 --json を実行してください。同等の絶対パスを使えば、どのディレクトリからでも実行できます。ランナーは Python ファイルをインポートして実行し、サンドボックス化は行わないため、先にアダプターを確認してください。ケースと結果の値は防御的にコピーしますが、アダプターのグローバル状態の管理はアダプターの作成者の責任です。終了コード 0 はサンプリングした契約に合格したことを示し、終了コード 1 は再実行可能なプロパティ違反を報告し、終了コード 2 は無効なアダプターまたはコマンドを報告します。

ナビゲーション

• 基本的な戦略の手順については、## Default Workflow、## Decision Rules、## Risk-Based Prioritisation、## Principles を参照してください
• 詳細な資料については、## Resources と ## Templates を参照してください
• ツール固有の実行引き継ぎについては、## Related Skills を参照してください

関連スキル

スキル	目的
qa-refactoring	動作を維持した安全なリファクタリング
software-code-review	コードレビューのプロセスとチェックリスト
software-architecture-design	システム設計とアーキテクチャの決定

学びのループ

過去の判断や落とし穴が関係する場合は、learnings.consolidated.md があれば参照してください。必要な履歴を確認する場合、または他に利用できるものがない場合に限り、learnings.md を使用してください。それ以外の場合は、どちらも参照しないでください。

適用後、覚えておく価値のあるパターン、防止すべきミス、または意外だった分野の事実に気づいた場合は、agents-skills-feedback-loop/scripts/append_learning.py を使って、日付付きの箇条書きを learnings.md に1つ追記してください。SKILL.md 自体は変更しないでください。