ソフトウェアの２つの正しさ

久しぶりに人の作ったシステムのテストをするという仕事をしています。テストを実行すること自体は単純作業なのですが、その作業項目を決めるテスト設計は何度やっても難しい作業だということを毎回実感させられます。だから、仕事でテストは結構好きなんですよね^*1。

今回の仕事では機能単体レベルのテストに加えて、プロダクトがユースケースに要求に準拠しているかどうかについても確認してほしい依頼されています。つまり、verification^*2だけでなく、validation^*3もやってほしいという高度な要求を突きつけられているわけです。

これまでもテストはいろいろやってきましたが、今回はそういうわけで一筋縄ではいかないのです。プロダクトが最終的にサービスのどのような位置を占めるのかとか、この機能はどのような形態になっていればビジネス的に価値があるのかというようなビジネス的なことも常に頭に置きながら進めないといけません。おそらく自分がプログラム開発する時以上に神経を使っていると思います。

† validationとverificationの違い

実は僕もこの２つの違いを正確に理解しているわけではないのですが・・・・

CD-Rなんかのデータが正確に書き込めたかどうかをチェックすることをverifyと呼ばれていることから、狙ったことが狙ったとおりにできているかどうかを検査するということであると理解しています。通常のプログラムのテストはバグを取り除くためのものなので、ほとんどの場合がverificationになるわけですよね。

verificationをすることによってプロダクトからバグはなくなりますが、これだけでプロダクトが完成したといえませんて。たとえプロダクトにバグがなくも、プロダクトは使えない場合があります。それはプロダクトが相手の要求に沿っていないプロダクトは何の価値も生み出さないからです。そのような状況を防ぐための作業がvalidationであると理解しています。

この際だからということでGoogleでしらべてみたらそのものずばりの「VerificationとValidation」というウェブがありました。

VerificationとValidation

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

端的に言うとこういうことなんですか。参考になります。

† 自分の傾向としては

普段は開発中心の業務に従事しているせいか、ガリガリと缶詰になってテストケースを書き起こしていると、どうしても頭がverificationのことでいっぱいになってしまう傾向にあるようす。

次の日にテストケースをvalidationという観点から眺めて見るとぜんぜん使えなかったりするので、テストケースは書いてから最低１日以上寝かせてから使うようにしています。

• ^*1: 本当にテストの実施だけに借り出されるのは嫌い。クリエイティビティのない単純仕事は苦手なのです
• ^*2: ベリフィケーション。「検証」と訳される
• ^*3: バリデーション。「妥当性確認」と訳される