ln-23-test-suite-auditor

テストスイート監査

目標： テストポートフォリオを、読み取り専用のライフサイクルおよび信頼性の仕組みとして監査します。どの重要な障害を検出できるのか、どの証拠が信頼できない、または古くなっているのかを特定し、どの追加、変更、統合、廃止、または明示的な省略によって、最小限で持続可能なポートフォリオを実現できるかを判断します。

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

ツールの使い分け

必要な作業	優先ツール	使用する条件	代替手段
ソースとテストのインベントリ	ネイティブのファイル一覧、検索、マニフェスト、テスト設定	ドメイン、テスト種別、ランナー、フィクスチャ、生成領域を把握する場合	リポジトリツリーと既知のテストエントリーポイント
テストとコードの関係	言語サーバーまたはホストネイティブのコードインテリジェンス	ユニット、呼び出し元、実装、ルート、テスト対象を対応付ける場合	命名とパスを検索し、直接読み込んで検証
実行と信頼性	シェル経由のリポジトリ定義テストコマンド	成功／失敗の状態、実行時間、実行順序への依存、再現性を確認する場合	CI の結果と設定を調査し、実行できない場合はその旨を記録
カバレッジと未検出の動作	既存のカバレッジツールとレポート	カバレッジデータが設定済みで、ソースの範囲と比較できる場合	静的な動作とテストの対応付け。割合を決して捏造しない
フレークと分離性の証拠	リポジトリでサポートされる、反復、シャッフル、並列、またはシード制御された実行	順序、時間、乱数、または共有状態への依存が疑われるテストがある場合	履歴、CI ログ、コードパスの証拠
アサーションの強度	テストの読み込み、失敗出力、設定済みのミューテーションテスト	テストが意味のある動作上の欠陥で失敗するかを判断する場合	特定のアサーションに基づく反実仮想の推論
フレームワークの仕様	テストランナーまたはフレームワークの公式ドキュメント	ライフサイクル、フィクスチャ、再試行、分離、モックの動作に所見が関係する場合	一次情報に基づくウェブ調査。それ以外は UNVERIFIED と記録

安全なテストコマンドと診断コマンドのみを実行してください。監査中にスナップショットを書き換えたり、ゴールデンファイルを更新したり、フィクスチャを再生成したり、出力の変更を受け入れたりしないでください。

エビデンスのルール

• カバレッジが示すのは実行されたことであり、証明ではありません。重要な動作には、アサーションまたは観測可能なオラクルを求めてください。
• 重要なジャーニーを唯一保護するのであれば、遅いテストでも価値が低いとは限りません。フレームワークの動作を証明するだけなら、速いテストでも価値が高いとは限りません。
• 不安定な失敗と、断続的に失敗する製品依存関係や、真に非決定的な要件とは区別してください。
• 削除を推奨するには、テストの根拠が古くなっていること、または引き続き必要なすべての動作と障害モードを、他のエビデンスが同等以上の信頼性で網羅していることを証明する必要があります。
• 統合を推奨するには、重複または分断されたカバレッジがあることを実証し、ビジネスシナリオと障害シナリオの違い、オラクルの強度、および障害箇所の特定能力を維持する必要があります。テストが大きければよいとは限りません。
• 既知のリグレッションを防ぐテストや、まれだが重大なエッジケースを証明する唯一のテストは、数値ヒューリスティックの値が低いという理由だけで削除候補にしてはいけません。
• 実際の依存関係があること自体は、テストの欠陥ではありません。そのバージョン、状態、所有者、リセット方法、可用性、および障害時のエビデンスによって結果の再現性が保たれるかどうかを評価してください。
• ポートフォリオの措置（KEEP、ADD、UPDATE、MERGE、DELETE、NO_TEST）と実行ステータス（PASS、FAIL、BLOCKED、UNPROVEN、QUARANTINED）は分けて扱ってください。NO_TESTには、既存の証明、別の統制、または残存リスクの明示的な受容が必要です。
• デフォルトで新しいレジストリを必須にしないでください。リポジトリ固有のテストパス、動作を表す名前、タグ、要件、CI 設定、レビューエビデンスから導き出せる追跡可能性を優先してください。
• 外部のテストガイダンスは、このテストスイートの具体的な弱点を説明している場合にのみ、実行可能な指針となります。

チェックリスト

1. ポートフォリオとベースラインを把握する

• テストランナー、設定、コマンド、ディレクトリ、フィクスチャ、ファクトリー、スナップショット、ゴールデンファイル、手動スクリプト、カバレッジ、およびミューテーションテスト用ツールを検出します。
• ソースの領域と重要なエントリーポイントを、ユニット、インテグレーション、コントラクト、エンドツーエンド、および手動テストの対象範囲に対応付けます。
• エビデンスがある場合は、要件、製品リスク、インシデント、公開コントラクト、および変更された動作をテストや結果にたどれるようにします。現在のテスト根拠がないテストと、信頼できる証明がない根拠の要素を特定します。
• リポジトリの指示と CI 設定を読み、必須のテストスイート、環境の前提条件、再試行、シャーディング、および除外項目を特定します。
• 可能であれば代表的なテストスイートと必須ゲートを実行し、環境、所要時間、終了ステータス、検出および実行された範囲、失敗、スキップ、再試行を記録します。必須テストスイートが何もテストを選択せずに終了する場合は、そのことを明記します。
• ポートフォリオを評価する前に、生成物、ベンダー提供物、例、マイグレーション履歴、およびインフラストラクチャのフィクスチャを製品テストから切り分けます。
• 監査は読み取り専用で行い、許可されたコマンドによって作成されたキャッシュやテスト成果物があれば明記します。

2. 製品価値とカバレッジを監査する

• 金銭、認証、認可、データ整合性、アルゴリズム、ドメインルール、破壊的操作、取り消せないワークフローなど、固有かつ重大なロジックを特定します。
• 重大な動作を、それに対応する不具合があれば失敗するオラクルを持つテストに少なくとも1つ結び付けます。名前やパスの一致、行カバレッジは、あくまで発見の手掛かりです。
• リポジトリ固有の設定、クエリ、スキーマ、適応、検証、障害処理、観測可能な結果を検証せず、言語、フレームワーク、データベースエンジン、ORM、HTTP クライアント、暗号化、シリアライザー、ライブラリの動作をただ再確認しているだけのテストを特定します。
• エンドツーエンドテストが、リスクに関連する本番環境を想定した境界を越え、途中のステータス、ページ、モック呼び出しだけでなく、最終的に永続化される結果やユーザーに見える結果を実証しているか確認します。
• エンドツーエンドで検証されていない重大なユーザージャーニーと、より低いレベルで動作がすでに確実にカバーされているコストの高いエンドツーエンドテストを見つけます。
• そのような障害が起こり得て、発生時のコストが高い場合は、エラー、再試行、タイムアウト、認可、並行処理、マイグレーション、互換性、復旧の動作を調査します。
• カバレッジデータを使って未実行の重大な経路を特定し、ギャップを報告する前に動作とアサーションを確認します。
• 影響度、起こり得る不具合、独自性、信頼性、保守コストを根拠として、重要なギャップと対象範囲内の影響を受けるテストをすべて KEEP、ADD、UPDATE、MERGE、DELETE、NO_TEST に分類します。有用な意図は残っているものの、その根拠、セットアップ、境界、アサーション、オラクルの変更が必要な場合は UPDATE を使用します。

3. 分離性と決定性を監査する

• テスト間で共有されるデータベース、ファイルシステム、環境、プロセス、ネットワーク、キャッシュ、時計、乱数生成器、グローバル状態に、漏洩がないか確認します。
• 成功時と失敗時のセットアップおよび後処理、一意なテストデータ、トランザクション境界、クリーンアップ、並列実行に安全なリソース所有権を確認します。
• 不安定なテストが疑われる場合は、原因を判別できる実行方法だけを使用します。単独実行、スイート内での実行、固定シードでの反復実行、順序のシャッフルまたは逆転、並列実行です。最初の失敗、実行順、シード、ワーカー、環境を記録し、証拠から原因が特定されるか、定められた診断予算に達した時点で終了します。
• 時刻、タイムゾーン、ロケール、乱数、スリープ、スケジューラー、競合への依存を検出し、動作がそれらに依存する場合は、制御可能な時計またはシードを必須とします。
• 実際の依存関係やエミュレーターについて、実物とモックのどちらが望ましいかを決めつけず、バージョンの固定、準備完了状態、名前空間や状態のリセット、失敗時のクリーンアップ、認証情報、CI での利用可否を確認します。
• 再試行と隔離のルールを見直し、最初の失敗と再現に必要な情報を保持していることを確認します。最初の失敗が暗黙の成功に置き換わらないようにします。
• 隔離したテストは、合格結果とは別に必ず見える状態にし、担当者または判断の手順と、具体的な復旧、置き換え、廃止の契機を設定します。隔離は実行状態であり、ポートフォリオ上の対応ではありません。
• 反復実行の証拠、ログ、失敗した経路を使って、テストの不安定さと実際に断続的に発生する製品の不具合を区別します。

4. 監査構造、保守性、オラクル

• テストの配置がソースのドメインに沿っているか、明確な種類別の規則に従っているか、またコントリビューターが担当テストを見つけられるかを確認します。
• 孤立したテスト、無効化されたテストスイート、重複するフィクスチャ、断片化したシナリオカバレッジ、肥大化したファイル、担当が分かりにくくなるフラットなディレクトリを探します。
• 一時的な特性評価、移行、互換性、インシデント、回避策、回帰テストを現在のリスクに照らして確認します。インシデントが解決しても、その回帰ガードを廃止する理由にはなりません。マージや削除を推奨する前に、対象の動作が不要になったこと、または信頼できる代替カバレッジがあることを求めます。
• テスト名と構成が、実装の説明ではなく、振る舞いの意図、前提条件、操作、期待される結果を示しているかを確認します。
• 観測可能な契約とロケール戦略に従い、プロジェクトで標準的に使われている安定した意味的ロケーター（ロール、アクセシブル名、ラベル）または明示的な ID／テストフックを使用します。スタイル、位置、タイミング、偶発的な構造への依存は避けます。文言が要件である場合は、文言の完全一致アサーションを別途扱います。堅牢な意味的ロケーターが存在する場合、フックを追加するためだけにプロダクトの変更を求めないでください。
• アサーションの具体性、否定の証明、状態とインタラクションのバランス、有用な失敗メッセージ、誤検知への耐性を点検します。
• 意味のある失敗オラクルがないテスト、弱い真偽値チェック、偶発的またはレビュー不能な出力のスナップショット、広範な例外の許容、テスト対象の動作を迂回するモックを指摘します。必要な契約を独立して証明するスナップショットや暗黙的な失敗オラクルは維持します。
• 期待値が、テスト内で実装の計算を再現したものではなく、独立した契約、例、不変条件、またはゴールデン成果物に基づいているかを確認します。
• モック、フェイク、エミュレーター、生成されたクライアントに契約のずれがないかを確認します。ずれによって誤った安心感が生じる可能性がある場合は、契約テスト、または実際の境界との信頼できる別の比較を求めます。
• デフォルト値でテストが成功すると、ポート、制限値、タイムアウト、パス、機能の動作がハードコードされていることを見逃す可能性がある場合は、デフォルト以外の設定値もテストします。
• 重要なオラクルの弱さが疑われる場合は、既存のミューテーションテストの結果、または安全を確認した対象限定の反実仮想テストを使用します。リポジトリ全体でのミューテーションテストは必須にしません。
• 手動テストについて、再現可能なセットアップ、即時失敗の動作、明示的な期待証拠、冪等性、後片付け、移植性、オペレーター向けドキュメントを確認します。
• フィクスチャとヘルパーの抽象化について、読みやすさとデフォルト値の妥当性を確認します。ビルダーに隠れた動作によって、重要なテスト条件が見えなくならないようにします。
• ゲートの配置とテストスイートのコストを確認します。必須ゲートは重大なリリースリスクを防ぎ、時間のかかる診断や探索的な証拠も発見できる状態に保ちつつ、通常のデリバリーを不必要に妨げないようにします。

5. 調査結果の検証と報告

• ライフサイクル、フィクスチャ、分離、再試行、またはモックの動作によって調査結果が変わり得る場合に限り、テストランナーまたはフレームワークのセマンティクスを調べます。公式のバージョン対応資料を使用します。
• 安全な場合は、重大度の高い信頼性の問題を再現し、コマンド、シード、順序、環境の証拠を保持します。
• 1つの根本原因（たとえば、グローバルフィクスチャによって複数の不安定なスイートが発生する場合）を共有する調査結果は重複を排除します。
• 重要性の基準を適用します。具体的な重大な証拠の欠落、誤った安心感、デリバリーリスク、または証拠で示された規模で繰り返し発生する保守コストを必須とします。好み、理論上の純粋性、一般論としてのベストプラクティス、仮定上の規模、妥当な代替案は却下します。望ましい実装ではなく、結果または制約を必須とします。
• 外部仕様に基づく修正は、バージョンに対応した公式の契約に根拠を置き、未解決のトレードオフには主要なエンジニアリング資料を使用します。裏付けのある仕組みを引用します。ローカルの欠陥にはローカルの証拠で十分です。
• 未証明のまま残る重大な動作、誤った安心感、デリバリーの阻害、保守上の負担に基づいて、調査結果を P0～P3 に分類します。
• 証拠がある場合は、意思決定に役立つポートフォリオの指標を報告します。証明状況別の重大なリスク、対応の内訳、必須ゲートの結果と所要時間、スキップ、再試行、隔離、孤立または陳腐化した候補などです。総テスト数、除外条件を示さない合格率、生のカバレッジ、レベル比率は、単独の品質目標として却下します。
• 必須の重大なスイート、環境、またはオラクルにアクセスできず、信頼できる静的または過去の代替証拠もない場合は BLOCKED を使用します。証拠から重大な動作が未証明である、必須ゲートに失敗している、または信頼できない重大な領域に誤った安心感が残っていると分かる場合は FAIL を使用します。ブロック要因ではないポートフォリオまたは保守上のリスクに限り CONCERNS を使用し、必須の証拠が信頼でき、重大な欠落が残っていない場合に限り PASS を使用します。

セルフチェック

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

出力仕様

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

1. 結果： スキル固有の判定と、裏付けられた結果。
2. 範囲： レビュー／変更した範囲、除外事項、ベースライン、重要な前提。
3. 証拠： 以下のスキル固有の項目。事実、推論、未検証の主張を区別します。成果物にリンクし、役立つ場合は表を使用します。
4. 検証： 確認項目と結果、入手できなかった証拠、該当するクリーンアップ／外部状態。
5. 完了状況： Checklist: X/Y complete。Incomplete: None または、各 UNPROVEN 項目について理由、結果への影響、具体的な次のアクションを記載します。残存リスクと必要な判断も示します。

スキル固有の証拠： テストの根拠／保護対象のリスク → 既存テストまたは証明の欠落 → ポートフォリオ上の対応 → オラクル → ゲート／結果 → 代替証拠または廃止の条件。証拠がある場合は、重大な動作、分離、保守性、アサーションの強さ、ライフサイクル、ポートフォリオ全体への影響、必須／診断ゲート、所要時間、スキップ、再試行、隔離を網羅します。調査結果には優先度、テストの場所、見逃す欠陥の種類、影響、許容できないトレードオフ、最小限の修正を含めます。固有のカバレッジを維持し、ポートフォリオ上の対応と実行状態を区別します。