ln-41-test-strategy-planner

テスト戦略プランナー

目標： 指定されたスコープについて、読み取り専用でリスクベースのテストポートフォリオの判断を策定します。重要なローカル動作への確信を最大化しつつ、固有の不具合シグナルをもたらさないテストの増加を防ぎ、影響を受けるエビデンスを保持、変更、統合、廃止、または意図的に省略する方法を定めます。

実行契約： 順序付きチェックボックスは完了の定義です。すべての項目を内部で PENDING、具体的なエビデンスがある PROVEN、該当条件が存在しないことを示すエビデンスがある CLEARED、または不足がある UNPROVEN として追跡してください。読み取り、委任、ツールの失敗は証明になりません。各セクションの後に項目を照合してください。回答を返す前に、すべての PENDING を解消し、PROVEN と CLEARED のみを数え、不足のすべてにスキルの判定ルールと承認ルールを適用してください。 ユーザーの意図、スコープ、既存の承認を維持してください。承認済みの作業は継続し、重大な選択肢が未解決の場合、または外部承認が必要な場合に限って確認してください。重大なリスクに応じて調査の深さを調整し、確認を暗黙に省略しないでください。依存関係と安全性の順序を守り、それ以外は各義務に適した検証方法を選んでください。

ツールの使い分け

必要事項	推奨ツール	使用する状況	代替手段
要件とリポジトリのルール	Git と標準のファイル読み取り機能	スコープ、現在の作業、受け入れ基準、サポート対象のコマンドを確認する場合	明示的な制約を含むユーザー提供の要件
既存のテスト範囲	ファイル一覧、検索、マニフェスト、ランナー設定、CI	テストレベル、フィクスチャ、環境、規約を把握する場合	リポジトリのツリーと既知のテストエントリーポイント
動作と境界	言語サーバーまたはホスト標準のコードインテリジェンス	エントリーポイント、利用箇所、信頼境界、永続化、キュー、外部契約を追跡する場合	範囲を絞った検索の後、直接調査する
既存のエビデンス	既存のテスト／CI レポート、テストの読み取り、安全なリポジトリコマンド	現在の証明に関する重大な不確実性が戦略を変え得る場合	実行上の制限を明示して静的エビデンスを使用する。計画を作るためだけにテストスイートを実行しない
現在の外部障害モード	公式ドキュメント、仕様、勧告、一次情報である現場のエビデンス	外部契約や実際のユーザー障害がシナリオや優先度を変え得る場合	主張を UNVERIFIED として記録する。リスクを捏造しない

調査は読み取り専用で行ってください。テスト、フィクスチャ、スナップショット、タスク、ドキュメントを作成せず、レビュー対象の実装を更新しないでください。

エビデンスのルール

• 重大なリスクごとに、それを証明できる最小の信頼性ある境界を選んでください。端から端までのジャーニーをより低いレベルでは確認できない場合は、エンドツーエンドのエビデンスを使用してください。異なる不具合を検出する単体、統合、契約の各証明は維持してください。
• カバレッジは発見のためのエビデンスであり、証明ではありません。特定した不具合で失敗するオラクルを求めてください。
• 影響度、起こり得る障害、固有性、検出可能性、復旧コストを基準に優先順位を付けてください。これらの判断を普遍的な数値基準に置き換えないでください。
• 既存テストが不足を補えるのは、そのセットアップとアサーションが同じ動作と障害モードを証明する場合に限られます。
• フレームワーク、言語、ORM、シリアライザー、ライブラリの動作は、ローカルの設定または統合によって契約が変わる場合を除き、プロダクトのテスト対象ではありません。
• ポートフォリオの判断と実行状況は分けてください。判断には KEEP、ADD、UPDATE、MERGE、DELETE、NO_TEST を使用し、エビデンスの状態にのみ PASS、FAIL、BLOCKED、UNPROVEN を使用してください。
• NO_TEST は明示的なリスク判断であり、作業の欠落ではありません。既存の証明、代替の統制、または受容した残存リスクを明記してください。
• テスト登録簿を継続的に管理するかどうかは任意です。規模やガバナンス上、別途管理する成果物が必要な場合を除き、リポジトリ標準のテスト名、パス、タグ、CI 設定、タスク出力を優先してください。
• 外部調査が有用なのは、この計画に具体的な障害モード、境界、またはオラクルを加える場合に限られます。

チェックリスト

1. 範囲と根拠を明確にする

• 機能、要件、受け入れ基準、関係者、明示的な対象外事項、人またはシステムが保護すべき成果を把握します。要求された仕組みと、それによって実現すべき結果を分け、計画対象となる具体的な動作がない場合は BLOCKED を返します。
• 該当するリポジトリの指示を読み、Git の状態を調べて、現在の作業や無関係な変更を既存の動作と取り違えないようにします。
• 言語、フレームワーク、ランナー、テストディレクトリ、フィクスチャ、ファクトリー、環境、CI ゲート、カバレッジ、コントラクトテスト、手動テストの対象を特定します。
• 既存の根拠と、要求された動作によって影響を受けるすべてのテストを各要件に対応付けます。根拠の実際の判定手段に基づき、実行状態は Evidence Rules に定めるとおりにして、カバレッジを完全、一部、不足、または利用不可として記録します。テスト名や対象箇所との近さは証明になりません。
• 自動テストスイートでは対象とされない動作を明らかにする場合は、手動、探索的、インシデント、製品環境の根拠を調べます。
• シナリオを提案する前に、環境、データ、認証情報、サービス、デバイス、ブラウザー、破壊的な状態に関する制約を特定します。
• テストレベル、優先度、実現可能性を左右する前提と不明点を記録し、解釈の違いによって戦略が大きく変わる場合に限り、簡潔な質問を1つします。

2. リスクマップを作成する

• アクターのトリガーから、エントリーポイント、ランタイムの配線、状態変更、永続的またはユーザーに見える結果まで、重要なフローをたどります。
• 金銭、認証、認可、所有権、データの完全性、破壊的操作、マイグレーション、公開コントラクト、不可逆なワークフローに関わる、ローカルで特に重要な動作を特定します。
• 想定される不具合の種類を列挙します。成功と誤判定するケース、有効な入力の拒否、無効な入力の受け入れ、境界値の誤り、部分的な失敗、重複配信、順序の誤り、タイムアウト、再試行、キャンセル、競合、ロールバック、復旧、互換性のずれです。保護すべき結果のうち何が失われるか、または具体的にどのような被害が生じるかを示します。
• プロダクトのリスクと実装の詳細、および依存関係によってすでに保証されている動作を区別します。ローカル固有の結果や判断を保護しない、技術的には表現可能な状態は対象外にします。
• プライバシー上機微なテストデータや規制対象のテストデータを特定し、合成、最小化、または明示的に承認されたフィクスチャを必須とします。
• バージョンに依存するコントラクト、繰り返し発生するユーザーの障害、不正利用のパターン、相互運用性のリスクによってマップが変わり得る場合に限り、最新の外部根拠を使用します。
• リスクを定性的に順位付けし、同順位や不確実性の理由を説明します。発生頻度や影響に関するデータがないのに、精密さを装ってはいけません。

3. ポートフォリオのアクション、レベル、オラクルを決定する

• 重要なリスクと影響を受けるテストそれぞれに、暫定アクションを1つだけ割り当てます。信頼できる固有の証拠が引き続き有効な場合は KEEP、重要なリスクが証明されていない場合は ADD、価値ある意図は残っているものの根拠、境界、セットアップ、またはオラクルが変わった場合は UPDATE、安全に統合できる証拠がある場合は MERGE、古くなった、重複している、些細である、または信頼できない証拠の場合は DELETE、別の制御または許容済みのリスクで十分な場合は NO_TEST を割り当てます。
• DELETE または MERGE では、テストの根拠が古くなっていることを証明するか、引き続き必要な重要な振る舞い、失敗モード、オラクル、有用な失敗箇所の特定をすべて維持する代替証拠を明示します。すでに存在するという理由だけで、古い証拠を残してはいけません。
• 分離されたローカルルールにはユニットテスト、プロデューサーとコンシューマー間の合意にはコントラクトテスト、自身が所有する境界にはインテグレーションテスト、下位レベルでは終端結果を証明できない本番環境に即した一連の操作にはエンドツーエンドテストを選びます。
• 各レベルで異なる失敗クラスを検出する場合を除き、同じ振る舞いをすべてのレベルで重複してテストすることは避けます。
• 必要最小限の独立したオラクルを定義し、コントラクトが求める場合は複数の観測結果を組み合わせます。対象には、返されるコントラクト、永続化された状態、発行されたイベント、レンダリングされた振る舞い、外部への作用、不変条件、または決定論的な成果物があります。
• モックやフェイクが、シナリオで証明するとしている境界や失敗の意味を迂回していないことを確認します。
• 観測可能なコントラクトとロケール戦略に沿って、プロジェクト標準の安定したセマンティックロケーター（ロール、アクセシブルネーム、ラベル）または明示的な ID／テストフックを使用します。スタイル、位置、タイミング、偶発的な構造への依存は避けます。文言そのものが要件の場合は、正確な文言のアサーションを別途扱います。堅牢なセマンティックロケーターがある場合、フックを追加するためだけにプロダクトの変更を求めてはいけません。
• リスクマップ上で重要な場合に限り、正常系、無効な入力、境界値、認可、エラー、復旧、並行処理、互換性のケースを含めます。
• 既定値ではハードコードされた振る舞いが見逃される可能性がある場合は、既定以外の構成、時刻、ロケール、ランダム性、順序、またはデータ規模を指定します。
• サポート対象のコントラクトまたは既知のリスクが判断に影響する場合に限り、ブラウザー、デバイス、オペレーティングシステム、ランタイム、またはバージョンの組み合わせを追加します。
• 決定論的なセットアップと範囲を限定したデータを優先します。実際の依存関係、エミュレーター、破棄可能な環境、または本番環境に近いトポロジーが必要な箇所を明示します。
• 各ポートフォリオアクションについて、リポジトリのゲートまたは診断上の役割、開始前提条件、証拠に基づく完了基準を定義します。完了基準にテスト数や生のカバレッジを使用してはいけません。

4. 優先順位付けされたテストマトリクスを作成する

• すべての判断について、テストの根拠、保護対象の成果、リスク、既存の証拠または影響を受けるテスト、ポートフォリオ上の対応、レベル、セットアップ、オラクル、期待される証拠、環境、ゲート、および判明している場合は結果の状態を明記します。
• 契約、移行、互換性期間、回避策、インシデント、依存関係、または一時的なリスクに価値が左右される証拠について、レビューまたは廃止のトリガーを定義します。責任者がいる根拠なしに日付を設定しないでください。
• 前提条件と状態の依存関係を維持しながら、安全性が重要なシナリオと情報価値の高いシナリオを、コストのかかる広範なテストより先に実行する順序にします。
• 並列実行できるシナリオと、変更可能な状態、レート制限、アカウント、デバイス、または環境セットアップを共有するシナリオを特定します。
• 失敗時の影響と必要な検出時間に基づいてゲートを分類します。リリース上重要なリスクを別の制御でカバーできる場合に限り、時間のかかる診断チェックを通常のゲートから分離します。
• 明示的に除外事項を記載します。保護対象の成果や不具合のシグナルに独自性がないシナリオ、重複の価値が低いシナリオ、フレームワークの動作、実現不可能な環境、および受容した残存リスクを含めます。
• 戦略が実行可能で、判断に必要な情報がすべて揃っている場合は READY を、有用な部分計画は可能でも重要な証拠が不足している場合は INCONCLUSIVE を、要件または安全性が重要な境界を確立できない場合は BLOCKED を使用します。
• リスクマップと判断台帳を照合します。重要なリスクや影響を受けるテストに、対応と裏付けとなる根拠が欠けていてはなりません。
• INCONCLUSIVE または BLOCKED の領域ごとに、証拠収集のための最小限の次のアクションを明記します。

セルフチェック

• 返却前に照合します。 項目単位の証拠、要件の網羅性、矛盾、スコープ、判定、および該当するクリーンアップを確認します。レポートまたは許可された成果物を修正します。有効な証拠を再利用し、リポジトリを自動的に再スキャンしたり、成功したコマンドを再実行したりしないでください。関連する変更、失敗、または未解決の証拠がある場合に限り、チェックを繰り返します。残る不足事項を開示します。

出力要件

ユーザーの言語で、次の順に報告します。5つすべてのフィールドを保持し、各事実は一度だけ記載します。結果が少ない場合はフィールドごとに1行で記載できます。空の表は省略し、リンク先の成果物をコピーしないでください。

1. 結果： スキル固有の判定と、裏付けのある成果。
2. スコープ： レビューまたは変更したスコープ、除外事項、ベースライン、および重要な前提。
3. 証拠： 以下のスキル固有フィールド。事実、推論、未検証の主張を区別します。成果物にリンクし、必要に応じて表を使用します。
4. 検証： チェックと結果、入手できない証拠、該当するクリーンアップや外部状態。
5. 完了： Checklist: X/Y complete、Incomplete: None、または各 UNPROVEN 項目の理由、成果への影響、正確な次のアクションを記載します。残存リスクと必要な判断も記載します。

スキル固有の証拠： 保護対象の成果 → 不具合の種類 → 影響 → 既存の証拠 → 優先度。影響を受けるテストまたはギャップごとに、ポートフォリオ上の対応、レベル／シナリオ／環境、独立したオラクル、必須または診断用のゲートと結果、レビューまたは廃止のトリガーを記載します。ポートフォリオ全体への正味の影響、根拠が明確な NO_TEST、価値の低い重複として除外した項目、環境要件、および結論が出ていない領域のための正確な証拠収集アクションを報告します。