長年、システムテスト（主にソフトウェアやエンタープライズシステム）の分野に身を置いてきましたが、物理学のバックグラウンドを持つ私は、コンピュータサイエンスを通じてテストに触れてきた多くの同僚とは、かなり異なる見方をしているという結論に達しました。物理学とは、（それが正しく機能しているならば）仮説、解釈、そして実験が互いに動機付けし合い、必要とし合う規律です。その核心にあるのは「測定」です。実験の構築方法は、問題に対する理解度を映し出すと同時に、データの取得と評価の手法、つまり一般に「物理量」と呼ばれるものへの変換プロセスを反映しています。物理量の値は、測定手順と単位に結びついて初めて意味を持ちます。この同じ原理は、修正を加えることなくソフトウェアの品質にも当てはまります。
しかし、これがソフトウェアプロジェクトにおいて適切に体現されているとは言えません。熟練した実務家として言わせてもらえば、プロジェクト全体の「インセプション（初期段階）」フェーズから、テストアーキテクトやテストアナリストが適切に参加しているケースには、めったにお目にかかれません。その結果、こうしたプロジェクトは定期的に、アドレナリン・スポーツのような意味での「冒険」へと変貌してしまうのです。
根本的行為としての測定
ケルビンの格言は明確です。「語っている事柄を測定し、数字で表現できるのであれば、それについて何かを知っていると言える。しかし、測定できないのであれば……あなたの知識は貧弱で不十分なものだ」。測定できない品質は単なる「意見」に過ぎません。定義された基準に従って測定された品質こそが「エンジニアリングの成果」なのです。エンジニアリング分野におけるテストは、原理的には同一ですが、科学的研究におけるそれとはわずかに異なる側面を持っています（少なくとも、単なる反復ではない一流の仕事を対象とするならば、の話ですが。これについてはまた別の機会に）。テストアーキテクトは、全体像の把握と広範なリスクアセスメントが必要とされる「テスト設計フェーズ」において、このことを最も深く理解しています。これについては、今後の投稿でさらに考察を深めるつもりです。これは極めて重要なテーマでありながら、一般的なソフトウェア文献でもあまりうまく扱われていない領域だからです。
この視点に立てば、テスト分析とは、要件定義書、アーキテクチャ契約、インターフェース定義などの「テストベース（テストの根拠）」から、測定可能な**テストターゲット（テスト目標）を導き出す行為に他なりません。テストターゲットとは、現代物理学（特に量子力学的な慣用句）で言うところの「可観測量（Observable）」**のエンジニアリング版です。つまり、指標（メトリクス）を首尾一貫して定義でき、合否判定基準を定式化できる、システムの厳密に指定された特性のことです。この導出ステップがなければ、テストは行き当たりばったりの探索となり、結果を再現することはできません。
サンプリング問題としてのカバレッジ
テストにおけるカバレッジ理論は、実験科学におけるサンプリング理論と鏡合わせの関係にあります。非自明なソフトウェアシステムに対する入力の可能性は、天文学的な規模に達します。システムの「状態空間」は、コード側からのボトムアップ・アプローチをとれば指数関数的に増大します。昨今流行しているエージェント型LLMベースの「AI」のような機械学習システムの導入は、起こりうる失敗モード（故障モード）の状況を改善するどころか、むしろ制御不能な自由度を増大させます。入力とシステム状態の両方において、経験的に関連のある機能（あらゆる境界値、境界内、境界外の状態を含む）をすべて網羅しようとする「網羅的テスト」は、組み合わせ論的な自殺行為です。
オートメーション化は、繰り返しのリグレッションテストを安価にし、機能に対して適切に書かれたテストスクリプト（データのパラメータ化）がある場合のテストを比較的容易にしますが、環境やデータセットの遷移に対するメンテナンスと制御が必要です。繰り返しになりますが、生成ツールはスクリプトの作成やモックデータの生成コストを劇的に下げますが、機能レベルでのカバレッジの正しさ（セマンティクス、つまり意味論は一筋縄ではいきません）を保証するものではなく、むしろテストスイートやテストデータのメンテナンスという側面の追加作業を生み出します。したがって、テストアナリストの任務は（他のプロジェクトメンバーと協力して）、互いに密接に関連する「データ入力空間」と「システム状態空間」を統計的に信頼できるレベルで網羅する、有限かつ代表的なサンプルを選択することにあるのです。
テストの不変性
「測定」としてのテストは、開発手法（メソドロジー）に左右されない「不変量」です。物理法則が測定手法の選択に依存しないのと同様です（定式化の方法は依存するかもしれませんが、それはまた別の話です）。機能が仕様通りに動作するか、しないか。スプリントの境界も、アーキテクチャのパターンも、その事実を変えることはありません。手法によって変わるのは、測定が行われる「頻度（カデンツ）」と、各測定時点で利用可能な「テストベースの範囲」だけです。これは、大規模なソフトウェアプロジェクトの経験者には自明のことでしょう。
ここで強調したいエンジニアリング・マネジメント上の帰結は、**「欠陥の修正コストは、混入地点と検出地点の距離が開くほど急激に上昇する」**ということです。これは単なる管理上の原則ではなく、ソフトウェアという成果物の構造的性質による帰結です。したがって、チームにテストアーキテクト、次いでテストアナリストを早期に関与させる経済的インセンティブは極めて明白です。これを財務的な観点から測定しようと試みることも可能ですが、私の経験ではそうした試みはめったに行われません。過去20年間で、バグに対する許容度は高まった一方で、納期やコストに対する許容度は悪化しているからです。しかしながら、早期のテスト分析を行うべきインセンティブは、上述した構造から直接的に導き出されるものなのです。