第7章：テスト自動化ソリューションの検証

7.1 インフラとTASの検証 (Verification of Infrastructure and TAS)

テスト自動化ソリューション（TAS）やテストスクリプトも、アプリケーションと同様に「コード」によって構築されたソフトウェアシステムです。そのため、自動テスト自体にバグが含まれていたり、実行インフラの設定ミスによって正しく検証できていなかったりするリスクが常に存在します。

シラバスv2.0では、自動テストを信頼するための前提として、TASおよびインフラストラクチャに対する**「検証（テストのテスト）」**の実施を求めています。

検証すべきコンポーネント

• テストスクリプトのロジック: 意図した通りの操作手順、および期待値との比較（アサーション）が正確に行われているか。
• テストデータ: 実行時に適切な初期データが投入され、クリーンアップ処理が正常に機能しているか。
• テスト自動化インフラ: 実行環境（コンテナ、仮想マシン、クラウド環境）、ネットワーク設定、外部モックサーバー、およびCI/CDの連携部分が安定して稼働しているか。

「テストのテスト」を実践するアプローチ

自動テストコードの妥当性を確認するために、意図的にテストを失敗させる環境を作ることが有効です。

• フォールトインジェクション（欠陥注入）: テスト対象（SUT）のコードやデータにあらかじめ意図的なバグを混入させ、自動テストがそれを「正しく検出して失敗するか」を確認します。もしバグがあるのにテストが成功してしまった場合、その自動テストの検証ロジック（アサーション）は機能していません。

---

7.2 偽陽性と偽陰性の管理 (False Positives and False Negatives)

自動テストの運用において最も警戒すべきは、テスト結果と実際のSUTの品質状態との間にズレが生じる**「偽陽性（False Positive）」と「偽陰性（False Negative）」**の発生です。これらを徹底的に排除することが、自動テストの信頼性を維持する鍵となります。

1. 偽陽性 (False Positive)

• 状態: テスト対象システム（SUT）は正しく動作している（バグはない）のに、自動テストが失敗（Fail）してしまう現象。
• 主な原因: 画面レイアウトの変更によるロケーター（要素識別子）の破損、通信のタイムアウト（レースコンディション）、テスト環境の不安定さ、テストデータの競合。
• 影響: 開発チームに「どうせまたテスト側のエラーだろう」というオオカミ少年効果（信頼の喪失）を生み出し、原因調査のために膨大なエンジニアリング工数が浪費されます。

2. 偽陰性 (False Negative)

• 状態: テスト対象システム（SUT）に致命的なバグが存在するのに、自動テストが成功（Pass）してしまう現象。
• 主な原因: アサーション（検証文）の欠落・不備、例外処理（エラーハンドリング）の誤りによってエラーを握り潰している、古い期待値のまま更新されていない。
• 影響: 本来見つけるべきバグを見逃し、重大な不具合が本番環境へ流出する（最も危険な状態）。

状態	SUTにバグがない	SUTにバグがある
テスト成功 (Pass)	正しい判定（真陰性）	致命的な見逃し（偽陰性）
テスト失敗 (Fail)	誤検知（偽陽性）	正しい判定（真陽性）

検証ロジックの正確性を継続的に担保する手法

• テストコードのピアレビュー: アプリケーションコードと同様に、テストスクリプトもチームメンバーで相互にレビューし、アサーションの漏れや不適切な例外処理がないかチェックします。
• 失敗傾向のモニタリング: 定期的にテスト実行ログを分析し、特定の環境や特定の時間帯だけで発生する「不安定な失敗（フラッキーテスト）」の原因を特定・リファクタリングします。