テストによく似た用語に、V&V（Verification and Validation）があります。「検証と妥当性確認」と翻訳されることが多いですね。さて、どう違うのでしょう。今回は、SWEBOK（Software Engineering Body Of Knowledge）の記述を参考にしながら考えてみましょう。SWEBOKはIEEEを中心にアメリカでまとめているソフトウェアエンジニアリングの体系です。邦訳はオーム社から「ソフトウェアエンジニアリング基礎知識体系」として出版されてます。英語版はフリーですので、英語が読める人は気軽に読んでみてください。SWEBOKは、テスト技術者が体系的に視野を広げてステップアップにつなげるのに適した、とても良い本だと思います。ちなみにSWEBOKのテストの章を書いているのは、イタリアが誇るソフトウェアテストの権威Antonia Bertolinoおばさま。海外のテスト業界は女性が幅をきかせているのですね。

さてテストとV&Vの違いは、どう書いてあるでしょうか。邦訳から引用してみましょう。

11.2.2 SQAおよびV&Vの目的と計画

V&Vは、より直接的にプロダクト品質を目的とし、テスティング（testing）をベースにして逸脱（deviation）を発見し、修正する。しかし、V&Vは、中間プロダクトの妥当性確認（validation）も行うために、したがってソフトウェアエンジニアリングプロセスの中間ステップの妥当性確認（validation）も行うことになる。

ちょっと難しい記述ですね。要するにV&Vはテストだけでなく、レビューやインスペクションなども入るということが書いてあります。V&Vとは、ソフトウェア開発の成果物にバグがないかどうかチェックする作業すべてだと考えておけばよいでしょう。プログラムを実行してバグを叩き出すのがテストで、プログラムやドキュメントなどを「実行させないで」バグを叩き出すのがレビューやインスペクションなどです。その両方を含むのがV&Vになります。両者を区別するために、テストを「動的テスト」と呼び、レビューやインスペクションを「静的解析」と呼ぶことがあります。静的解析には他に、メトリクス分析やデータフロー解析なども含まれるようです。でも、だからといって、始めのVがテストで、後ろのVが静的解析とは限りません。

V&Vの始めのVは、"verification"のことです。フロッピーディスクやCD-Rにデータを書き込んだ後に正しく書き込めたかどうか確認することを、ベリファイ（verify）と言いますね。僕は、2つのものが同じかどうか比較する、という意味だと捉えています。SWEBOKには、どう書いてあるでしょうか。「11.2.2.3 V&V計画」に説明があります。

　検証（verification）アクティビティは、特定のプロダクト、すなわちプロセスの成果物を検査し、定められた要求が満たされたという客観的証拠を提供する。「定められた要求」とは、検査（examine）される成果物の要求のことを指し、それが導出されたプロダクトと相関がある。例えば、コードは、設計記述の要求に関連して検査（examine）され、ソフトウェア要求はシステム要求に関連して検査（examine）される。

verificationについて理解するには、「プロセス」という考え方を理解しておく必要があります。ここでいうプロセスとは、ウォーターフォールプロセスとかスパイラルプロセスとかラショナル統一プロセス（RUP）という“ソフトウェア開発の流れ全体”ではありません。プログラミングとか要求定義といった、“ソフトウェア開発の一つ一つの作業のまとまり”のことです。「アクティビティ」と呼ぶ方が適切という意見もあると思います。

プロセスとは、入力を出力に変換する作業のことです。難しい表現ですね。どういうことでしょうか。例えばプログラミングプロセスであれば、詳細仕様を見ながら、その仕様を満たすようにソースコードを書いていくと思います。この場合、詳細仕様が入力で、ソースコードが出力になります。詳細仕様は、その前の詳細設計プロセスの出力になるわけですから、ソフトウェア開発はプロセスが数珠つなぎになったものだと捉えることができますね。それぞれの数珠の玉がプロセスです。数珠の間で受け渡しされるのが、前のプロセスの出力であり、後のプロセスの入力です。これを中間成果物と呼びます。

さてverificationの話に戻りましょう。verificationとは、プロセスの入力と出力が合致しているかどうかを付き合わせて比較し、間違いがないかどうかチェックすることです。プログラミングプロセスのverificationは、コードレビューであり、単体テストです。コードレビューでは、プロセスの入力である詳細仕様と、プロセスの出力であるソースコードを付き合わせてチェックしますね（もちろんコードレビューでは他にもやることがあるのですが、とりあえず考えないことにします）。単体テストでは、プロセスの入力である詳細仕様と、プロセスの出力であるソースコードの代わりとしてソースコードの実行結果を付き合わせてチェックします。プロセスの出力か代用品かという違いはあるものの、プロセスの入力と出力を付き合わせてチェックすることには変わりありません。

ではV&Vの二つ目のVは何でしょうか。"Validation"のことです。validaitonの語源はラテン語のvalidusだかvalereで、力強いとか、健康になるとか、幸せとか、価値があるとか、そういうことのようです。僕は、良いかどうか調べる、とという意味だと捉えています。SWEBOKには、どう書いてあるでしょうか。やはり「11.2.2.3 V&V計画」に説明があります。

　妥当性確認（validation）は、特定されたプロダクトを検査（examine）し、特定の意図された効用に対する要求が達成されたという客観的証拠を提供する。妥当性確認（validation）は、プロダクトがソフトウェアシステム要求へと遡及追跡し、それを満たしていることを確認する。このことは、システム及びソフトウェア要求プロセスと、多かれ少なかれ並行して、システムテスティング（system testing）を計画することを含む。妥当性確認（validation）のこの側面は、一般に要求検証（requirements verification）アクティビティの一部として機能する。

要するに、ソフトウェアが要求を満たしていることをチェックする、ということのようですね。プロセスとか何とか難しいことは置いといて、とにかくソフトウェアがお客さんを満足させているかどうか、がvalidatoinのようです。これは分かりやすい考えです。

理詰めでモノを考える人は、ここで疑問を感じると思います。verificationを全てきちんとやっておけば、ソフトウェア開発の一番最初の入力である要求と、一番最後の出力であるソフトウェアが合っているかどうかチェックできるのではないでしょうか。すなわち、verificaitonがあればvalidationはいらない、と思いませんか。

まぁ理屈としてはそうなのかもしれませんが、実際には両方必要です。プロセスの入力と出力が全て対応できるとは限らないからです。例えば顧客の要求は、全て仕様には反映されません。要求仕様をきちんと全て反映している設計ばかりであれば苦労しません。伝言ゲームと同じように、プロセスが複数連なると大きなずれが生じてきます。ですからverificationとvalidationは両方必要です。賢い人ほど誤解しますので、気を付けてくださいね。

ところでverificationとvalidationの違いは、Boehm御大が分かりやすくまとめています。

verification：

Are we building the product right? （正しく製品を作っているか）

validation：

Are we building the right product? （正しい製品を作っているか）

ところでvalidationは、「妥当性確認」と訳すのが普通なんですが、僕はあまり好きではありません。妥当性が意味するのは、必要最低限の満足なような気がしませんか。validationで行うべきなのは、必要最低限の満足が提供されているかどうかを確認するのではなく、上を見ればキリがない顧客の満足をどの程度達成できているかどうかを「評価」することだと思います。テスト技術者の仕事が仕様の確認ことから、お客様にどのくらい満足して頂けるかどうかを評価すること、になっていくといいですね。その方が楽しいじゃありませんか。

ValidationとVerificationには、本稿通り「目的(目標)とする状況が達成できているかどうか判断する」と「達成できているかどうかを実証する」という並置される関係もあると思いますが、ValidであることをVerifyするという目的(状況)と動作(状況への働きかけ)という関係もあるような気がします。
V&Vというのはアメリカ人の好きな語呂合わせ的な面も多少あるような気がします。