testing-strategies

テスト戦略

主な質問が**「どの検証パケットを信頼するのか、実際にどの程度の信頼性が必要なのか、チームは次に何をすべきなのか？」**である場合は、このスキルを使用してください。

役割は、一般的なピラミッド／トロフィー論を並べたり、テストコードを書いたりすることではありません。 役割は次のとおりです。

1. 現在のポリシーパケットを標準化する
2. 実際にどのゲートを判断しようとしているのかを明示する
3. 主となるポリシーモードを1つ選ぶ
4. 納得できる最小限のレイヤー構成を明示する
5. ローカル／PR／リリース／定期実行で期待される内容を分ける
6. 例外と不安定なテストに関するルールを正直に述べる
7. 実装、デバッグ、リリース実行、アクセシビリティ、ゲーム起動、パフォーマンスに関する作業は、直ちに適切な場所へ案内する

不慣れなポリシーパケットを扱う前に、references/intake-packets-and-route-outs.mdを読んでください。 曖昧さの本質がブランチをブロックする条件とリリース時のみの確認、またはプラットフォーム起動時の証明の違いにある場合は、references/gate-truth-and-release-handovers.mdを読んでください。 納得できる最小限のレイヤー構成を選ぶ際は、references/validation-matrix.mdを読んでください。 次のステップをtesting-strategies、backend-testing、debugging、code-review、performance-optimization、web-accessibilityのどれが担当すべきか判断する際は、references/handoff-boundaries.mdを読んでください。

このスキルを使用する場合

• 曖昧な「テストをもっと追加する」という助言ではなく、変更に基づく検証ブリーフが必要な場合
• 開発者またはレビュー担当者が、ローカル、PR、リリース前、定期／夜間の実行で何を実施すべきか尋ねている場合
• 単体テスト、結合テスト、コントラクトテスト、スモークテスト、探索的テスト、手動チェックが本当に必要か判断する必要がある場合
• 不安定または高コストなテストスイートの問題が、実際にはゲートポリシーの問題である場合
• 本番流出したバグやインシデントに対して、広範なE2Eテストをむやみに増やさず、適切な回帰防止策が必要な場合
• リリース準備やQA承認の作業を、実際の変更リスクに結びつける必要がある場合

このスキルを使用しない場合

• 主な作業がAPI／サービス／データベース／ブラウザーのテスト、フィクスチャ、モック、またはtestcontainersの実装である → backend-testingまたはスタック固有の実装スキルを使用してください
• 主な作業が障害の再現、テストが失敗する原因の特定、不安定な動作のデバッグである → debuggingを使用してください
• 主な作業が特定のPR、差分、またはマージリクエストの評価である → code-reviewを使用してください
• 主な作業がアクセシビリティを重視した検証、またはビジュアルレビューのポリシーである → web-accessibilityまたはweb-accessibilityを使用してください
• 主なリスクがパフォーマンスのベンチマーク、負荷テスト、またはフレーム予算のポリシーである → performance-optimizationまたはgame-performance-profilerを使用してください
• 実際の変更や判断事項がまだない場合は、まず何が変わったのか、どの信頼性判断が必要なのかを定義してください

手順

ステップ1：手元にあるポリシーパケットから始める

references/intake-packets-and-route-outs.mdを使用してください。

現在のパケットを、次のいずれかの形式に標準化してください。

• change-risk-packet — 機能、バグ修正、移行、API変更、認証変更、UIフロー変更、設定／デプロイ変更、またはインシデントのフォローアップ
• gate-design-packet — ローカル、PR、リリース、定期実行の各ゲートに何を含めるべきかチームが議論している
• flake-cost-packet — テストスイートが遅い、ノイズが多い、壊れやすい、または高コストで、ポリシーが不明確
• release-readiness-packet — ステージングでのスモークテスト、承認、ロールアウト、またはチェックリストの作業があるが、どのレイヤーが担当するのか曖昧
• incident-ratchet-packet — 本番流出したバグや停止への修正に、最小限かつ継続的な回帰防止策が必要

有用な最小限の枠組みを記録してください。

Packet: change-risk-packet
Change type: API contract + DB migration
Hotspots: compatibility, migration safety, permissions
Decision point: PR + release
Current evidence: unit tests only

ルール：ユーザーがすでに持っているパケットから始めてください。有用な作業を始める前に、理想的なQAテンプレートを要求してはいけません。

Step 2: レイヤーを選ぶ前に、ゲートの実態を明確にする

現時点で実際の意思決定ポイントがどれかを示します。

• merge-gate-truth — ブランチをブロックする証拠、必須ステータスチェック、またはレビューをブロックする証明
• release-gate-truth — ステージングでのスモークテスト、ロールアウトの安全性、ロールバックに関するメモ、権限、パッケージング、または人による承認
• scheduled-breadth-truth — 信頼性を高めるものの、すべての PR をブロックすべきではない、夜間／cron／マトリックスによるカバレッジ

ルール：

• 保護ブランチ向けツールをテスト戦略の全体であるかのように扱わないでください。これはブロック対象の一部を強制するだけです。
• リリース／プラットフォームのチェックリストが、実際にはローンチやロールアウトの担当範囲であるのに、PR ゲートへひそかに範囲を広げることのないようにしてください。
• 複数のゲートがある場合は、主ゲートと後続ゲートを明示してください。

Step 3: 主ポリシーモードを1つ選ぶ

主モードをちょうど1つ選びます。

• layer-selection — 変更された動作を検証するには、どの検証レイヤーが必要ですか？
• gate-shaping — ローカル、PR、リリース、定期実行の各ループには何を含めますか？
• flake-and-cost-policy — 何をブロック対象にし、隔離し、移動し、または情報提供のみとしますか？
• incident-regression-ratchet — 流出したバグを検出できた最も低いレイヤーはどれですか？
• release-confidence — 正直なところ、最後にどのスモークテスト、チェックリスト、またはロールアウトの証明が必要ですか？

任意で副モードを1つ指定できますが、テストに関するあらゆる話を同じチェックリストに押し込まないでください。

Step 4: リスク層とクリティカルパスを分類する

簡潔なリスクモデルを使用します。

• Tier 0 — 低リスク： ドキュメント、コメント、デッドコードの削除、影響範囲が限定された名前変更、明白な設定メタデータ
• Tier 1 — 通常のプロダクト変更： 影響範囲が限定された一般的な機能追加またはリファクタリング
• Tier 2 — 高リスク： パブリック API、マイグレーション、認証、課金、外部連携、ステートマシン、並行処理、バックグラウンドジョブ
• Tier 3 — リリース上重要／インシデント関連： 流出したバグ、障害の修正、ロールバックに影響されやすいデプロイ経路、または重要な顧客の利用経路

以下を記録します。

• クリティカルパスと影響を受けるユーザー
• 失敗時のコスト：煩わしさ、機能の破損、信頼の損傷、データ損失、ロールアウトのリスク、セキュリティリスク
• すでにある証拠：テスト、スクリーンショット、プレビュー、ログ、コントラクトに関するメモ、ロールアウトに関するメモ、チェックリスト
• 意思決定ポイント：ローカルでの信頼性、PR／マージ時の信頼性、リリース時の信頼性、または長時間実行する定期的な広範囲検証

変更が複数の層にまたがる場合は、最も高い層を基準に計画します。

Step 5: 納得できる最小限のレイヤー構成を選ぶ

references/validation-matrix.md を使用します。

レイヤー選択の既定値：

• ロジック、検証、分岐、またはマッピングが主なリスクの場合は、ユニット／コンポーネント／サービス
• 配線、DB のセマンティクス、ミドルウェア、シリアライズ、ジョブ、または実際の依存関係の動作が重要な場合は、インテグレーション
• レスポンスの形状、スキーマ、イベント、またはサービス間／クライアント間の境界に変更があった場合は、コントラクト／API レベル
• 複数のレイヤーで重要なエンドツーエンドの利用経路をまとめて検証する必要がある場合は、スモーク／選択的 E2E
• 視覚的な細部、デバイスごとの差異、運用上のエッジケース、または人による承認が依然として正直な答えである場合は、手動での探索的検証／チェックリストによる検証

次の両方を必ず明示します。

• 今、必須のもの
• 現時点では意図的に対象外とするものとその理由

例：

• 「今はインテグレーション＋コントラクト。ユーザーの利用経路に変更がないため、広範なブラウザー E2E は実施しない」
• 「リリーススモークテストとロールアウトチェックリスト。唯一のリスクはステージングの設定とデプロイ時の動作にあるため、新たなユニットテストは実施しない」

Step 6: ローカル、PR、リリース、定期実行で求める内容を分ける

有用なポリシー概要では、どのループにも同じテストスイートが適しているかのように扱いません。

実態に即した最小限のゲート分割を定義します。

• ローカル — 高速で低コストな、開発ループ向けの検証
• PR / マージ — リスクの高い経路における変更箇所への確信
• リリース — 本番環境向けスモークテスト、マイグレーションの安全性、ロールアウトの確認、または手動承認が必要な項目
• 定期実行 / 夜間 — 広範なマトリックス、高コストの組み合わせ、互換性の一斉確認、長時間実行のテストスイート

判断の目安：

• PR に対して遅すぎる、または不安定すぎるテストスイートは、延々と再実行するのではなく、意図的に別のタイミングへ移します
• ブランチ保護 / 必須ステータスチェックがある場合は、マージを本当にブロックすべきチェックだけを挙げます
• リリースチェックリストがある場合は、人による検証がなお必要な具体的なリスクと結び付けます
• ストア / プラットフォームのローンチチェックリストが主な作業になっている場合は、マージ時のカバレッジに無理に含めず、ローンチまたはデリバリーの担当者に引き継ぎます
• その資料が実際にはリリース調整のためだけのものなら、すべての項目をテストレイヤーの選択であるかのように扱わず、そう明記します

Step 7: 例外とフレーキーなテストへの対応ルールを明記する

ここで戦略が実務に落とし込まれます。

以下を明記します。

• どのチェックがブロッキングで、どれが情報提供のみか
• フレーキーなテストを隔離する、修正する、定期実行に移す、またはゲートから外すタイミング
• 回帰を新たにカバーしない場合に必要な説明
• ここでカバレッジ率が重要なのか、それとも背景情報として報告するだけなのか
• 手動検証が一時的なものか、リリース時のみか、長期的に意図された選択なのか

適切な初期設定：

• フレーキーな状態が繰り返されるのはポリシー上の問題であり、単なる再実行の習慣ではありません
• 隔離によって CI のノイズを減らせますが、担当者、期限、フォローアップを明確にしておく必要があります
• 「カバレッジが上がった」ことは、リスクのあるシナリオが保護された証拠にはなりません
• すり抜けたバグは、実際に検出できた最も低いレイヤーの回帰テストに反映していきます

Step 8: 次の担当者にすぐ引き継ぐ

このスキルが担当するのは、ポリシーと確信度の判断であり、後続作業のすべてではありません。

よくある引き継ぎ先：

• backend-testing — 選択した API / サービス / データベース / フィクスチャ / コントラクトテストの作成または修復
• debugging — 現時点でテストスイートが失敗する、不安定である、または環境依存である理由の調査
• code-review — ある差分について、現時点の検証結果で承認に十分かどうかの判断
• deployment-automation — ゲートの決定後のロールアウト実行、ステージング / 本番環境の検証順序、ロールバック手順、またはリリース手順書の担当
• game-ci-cd-pipeline — 問題がポリシー選定ではなくゲームの CI/CD に関わる場合の、エンジン / ビルドパイプラインの実装または安定化
• steam-store-launch-ops — 残る確認事項がマージ時の確信度ではなく、リリースチェックリスト、ページの準備状況、またはローンチ時期の場合の、Steam 固有のローンチ / ストア / 手順書の担当
• web-accessibility / web-accessibility — アクセシビリティ中心、またはビジュアルガバナンスに関する検証資料への対応
• performance-optimization / game-performance-profiler — パフォーマンスが実際の主なリスクである場合の、ベンチマーク、負荷、レイテンシー、またはフレーム予算に関するポリシーへの対応

ユーザーが「何をテストすべきですか？」と尋ねたら、このスキルで対応します。 「そのテストをどう書くか、または安定させるか」と尋ねたら、別のスキルに引き継ぎます。

Step 9: 簡潔な検証概要を 1 つ作成する

推奨形式：

# Validation Strategy Brief

## Policy packet
- Packet:
- Gate truth:
- Primary mode:
- Risk tier:
- Decision point:

## Required validation now
1. [Layer] ... because ...
2. [Layer] ... because ...
3. [Manual / release check] ... because ...

## Gate split
- Local:
- PR:
- Release:
- Scheduled:

## Out of scope for now
- ...

## Exception / flake policy
- ...

## Next owner
- `backend-testing` / `debugging` / `code-review` / other

長大なテスト宣言より、短く明確な概要のほうが適切です。 正直な答えが「適切なレイヤーで、テストを減らすこと」なら、そのまま明言します。

出力形式

必ず検証戦略の概要、ゲート調整のメモ、または回帰対策の概要を返します。

必須事項：

• すでに手元にある資料を特定する
• レイヤーを追加で広げる前に、判断対象となる実際のゲートを明記する
• 主なポリシーモードを 1 つ選ぶ
• リスクとクリティカルパスを明確に分類する
• 該当する場合は、ローカル、PR、リリース、定期実行で求める内容を分ける
• 意図的に対象外とする項目を曖昧にせず、その理由を説明する
• 実装、デバッグ、レビュー、アクセシビリティ、またはパフォーマンスに関する作業を、適切な関連スキルに引き継ぐ

例

例 1：API ＋マイグレーションパケット

入力

この PR では API コントラクトを変更し、DB マイグレーションを追加します。マージ前にどのような検証を必須にすべきですか？

出力案

• パケット：change-risk-packet
• ゲートの判断基準：merge-gate-truth
• 主なモード：layer-selection
• リスクレベル：2
• 必須の検証：
  1. マイグレーションの読み書きパスに対する統合テスト
  2. レスポンスの互換性に対するコントラクト／API チェック
  3. 最も重要なコンシューマーパスに対するリリース時のスモークテスト
• 対象外：ユーザーフローに変更がないため、広範なブラウザー E2E は対象外です
• 次の担当：backend-testing

例 2：不安定なブラウザースイートのパケット

入力

Playwright スイートの実行が遅く、何度も不安定になります。このリポジトリでは、どのようなテスト戦略を採用すべきですか？

出力案

• パケット：flake-cost-packet
• ゲートの判断基準：merge-gate-truth。その後の対応として scheduled-breadth-truth
• 主なモード：flake-and-cost-policy
• 必要な変更：
  1. PR のブラウザーカバレッジを重要なユーザージャーニーのみに絞る
  2. より広範な組み合わせはスケジュール実行に移す
  3. 不安定さが繰り返される場合の隔離／修正ルールを定める
  4. 妥当であれば、より低レベルの統合／コンポーネントチェックに信頼性の確認を移す
• 次の担当：実装は backend-testing、現在の不安定さの根本原因の特定は debugging

例 3：リリース準備状況パケット

入力

エンジニアリングチームによるとテストはすべて成功していますが、このリリースの前にほかに何か必須にすべきことはありますか？

出力案

• パケット：release-readiness-packet
• ゲートの判断基準：release-gate-truth
• 主なモード：release-confidence
• 必須の検証：
  1. 変更された顧客のユーザージャーニーに対する、ステージング環境での対象を絞ったスモークテスト
  2. デプロイの形態が変わった場合は、マイグレーション／ロールバックのチェックリスト項目
  3. スケジュール実行のカバレッジを超える、新たな広範な回帰テストは不要であることを明記
• 振り分け：変更が UI の状態に大きく関わる場合、アクセシビリティに特化した承認は web-accessibility に振り分けます

例 4：ゲームのローンチチェックリストパケット

入力

ビルドは CI に合格しましたが、Steam のリリースチェックリスト項目とパッケージング作業がまだ残っています。この作業もここで扱いますか？

出力案

• パケット：release-readiness-packet
• ゲートの判断基準：release-gate-truth
• 主なモード：release-confidence
• 必須の検証：対象を絞った最終スモークテストと、ローンチ／ビルドのチェックリスト項目が満たされていることを示す最低限の証拠
• 対象外：ストア／プラットフォームのローンチ作業が残っているという理由だけで、ブランチをブロックする PR チェックを拡大すること
• 次の担当：steam-store-launch-ops および／または game-ci-cd-pipeline

ベストプラクティス

1. 好みのテスト標語ではなく、すでに手元にあるパケットから始めます。
2. リスクのある動作を証明できる範囲で、最も低コストのレイヤーを優先します。
3. ローカル、PR、リリース、スケジュール実行の各ループを明確に区別します。
4. 不安定なテストは、単に再実行すればよいという問題ではなく、ポリシー上の問題として扱います。
5. リリースチェックリストを独立したものとして扱わず、実際のリスクと結び付けます。
6. 意図的に除外した項目を明記し、残存リスクを見えるようにします。
7. すり抜けたバグを踏まえて、そのバグを検出できた最も低いレイヤーに回帰テストを追加します。
8. マージをブロックするチェック、リリース時のみの検証、スケジュール実行の広範な検証を混同せず、明確にします。
9. 実装は backend-testing、原因究明は debugging、ロールアウトの実行は deployment-automation、プラットフォーム／ゲームのローンチ作業は steam-store-launch-ops または game-ci-cd-pipeline、アクセシビリティに重点を置いた検証は web-accessibility に振り分けます。
10. 手動検証が妥当な答えであるなら、後ろめたく思わずに採用します。
11. 簡潔な検証概要は、巨大なテスト宣言よりも再利用しやすいものです。

参考資料

• Martin Fowler — テストピラミッド
• Martin Fowler — 実践的なテストピラミッド
• Google Testing Blog — エンドツーエンドテストを増やすのはやめよう
• Selenium — テストの実践
• Playwright — ベストプラクティス
• Pact ドキュメント