ソフトウェアテストの２つの見方
先のエントリは、QAのプロからみたら絵に描いた餅にみえるのかもしれない。日ごろから感じているんだけど、ソフトウェアテストに対して、2つの見方がある。
- システムの正しさを証明する、という見方
- システムの間違いを発見する、という見方
最初のほうは非常にナイーブな考え方で、ソフトウェア開発の経験が浅い新人さんなんかはたいていこっち。彼らの見方では、ソフトウェアテストを数学の証明と同じように取り組むのでテストを任せると、うんうんうなった挙句、
「テストってどうやってやるんですか?」
と先輩に聞くようになる。要するに、証明問題があまりに難しいので根を上げるわけ。
そして、ある程度経験をつんで、実際にはシステムはあまりに複雑なんで正しさなんか証明できないんだよ、ということに気づく。ここで単純にあきらめてしまうと、実務年数だけ長い品質の概念のない開発者になってしまう。でももうちょっとまともな人は、完全な証明はできないけどリスクを減らそう、と考えるようになる。後者の人は、マトリクスなどから大量のケースでまず網羅性を確保して、そこから効率よくテストする方法を探るようになる（と思う）。
で、QAのプロはほぼ間違いなく後者の見方で、そのほうが「正しい」ソフトウェアテストの見方だと思われる。だから、ある程度経験をつんだ人に「プログラムが正しいことを証明しよう」なんて言うと、わかってないのね、って感じの冷たい反応が返ってくることが多い。
でも個人的には、開発者は前者の視点を捨ててはもったいないかもと思っている。QAのテストはたいていカオス渦巻くシステムレベルなんだけど開発者は関数レベルの単純な世界でテストができる。場合によっては数学的な証明も可能なんじゃないだろうか。*1
-
- -
そうそう。実はテストにはもうひとつの見方があった。
これを忘れていたのはちょっとイタイ。
- システムの動作がリファレンスと同じことを確かめる。
リファレンスが過去のバージョンならリグレッションテスト。
リファレンスが別の実装ならそれはFunction Equivalence Testing。
（Cem Kaner教授のスライド 参照）
コンフォーマンステストもこの範疇に入るのかもしれませんな。
