テストの本質を探る　――30年の歴史を持つ 「ソフトウェア工学」の知恵に学ぶ

●二つの"V"

　ソフトウェアの世界では，厳密にはテストを次の二つに分けて考えます．単純に「開発の最終工程の検査」としてのテストだけでは，十分にソフトウェアの品質を確保することができないためです．二つのこととは「検証」と「妥当性確認」のことで，端的に"V&V"と呼ばれます（コラム「V&Vのいろいろ」を参照）．

• 検証（verification）
  　検証とは，あるフェーズにおいて，そのフェーズの最初の段階で課せられた条件を満足しているかどうかを判定するために，システムないしはコンポーネントを評価するプロセスのことを指します．
  
• 妥当性確認（validation）
  　妥当性確認とは，開発プロセスの最後の段階において，記述された仕様を満足しているかどうかを評価するプロセスを指します．もし，完全に検証が行われていれば，仕様に対して設計が正しくなされ，設計に対して実装が行われるわけですから，プログラムは仕様を完全に満足していることになります．

　V&Vを明確に区分した開発プロセスとして，有名なものにクリーン・ルーム手法があります（図3）^3）．クリーン・ルーム手法では明確に仕様を定義し，フェーズごとに段階的詳細化を通じて検証を行います．テストは仕様に対して実施され，妥当性の確認が行われます．

　ちなみに，クリーン・ルーム手法には，そのほかにも興味深い特徴があります．まず，各フェーズの担当者を明確に分離しています．また，利用モデルを用いた統計的なテストを行います．すなわち，よく利用される部分はしっかりと確認行為としてのテストを行います．ある使いかたを想定したうえでのテストなので，実際にテストした部分とそうでない部分が出てきます．これによって，開発したソフトウェアについては，「完全なものです」とは言わず^注2，「あるMTTF（mean time to failures；平均故障時間）を保証します」という言いかたができるようにします．

　もともと段階的詳細化を行っているため，クリーン・ ルーム手法に基づいて開発されたプログラムはエラーが少ないと考えられます．したがって，確認行為としてのテストは利用モデルに基づいて行うだけになります．不ぐあい検出を目的とするテストであれば，このように割り切ることはできません．クリーン・ルーム手法は，「エラーが少なくなるように開発する」，「ソフトウェアの使いかたに基づいて統計的にテストする」，「信頼性の高いソフトウェアを作る」といった目標を達成するための一つの方法を示しています．

 注2；普通は，「何かが起こるかもしれないが，わたしは責任をとらない」という言いかたかもしれない．

〔図3〕クリーン・ルーム手法におけるプロセス
仕様は，ボックスと呼ばれるものを用いて関数仕様という形で記述する．ボックスには，ふるまいを表現した「ブラックボックス」，データによる状態を表現した「状態ボックス」，手続きを表現した「クリアボックス」がある．この順番に詳細化していき，最終的にプログラムを得る．テストは，システムに対する利用モデルに従って行う．この結果得られたMTTF（mean time to failures；平均故障時間）によって，そのソフトウェアを受け入れるか否かを判定する．「クリーン・ルーム」という名称の由来は，半導体製造に用いられるクリーン・ルームである．各工程でエラーが混入しなければ，良い最終製品ができ上がるという考えかたに基づいている．