テストすることについて

今さらですが、最近テストについて考えているのですが、これがなかなか難しい壁に直面しています。

チームで開発する、仕事で開発する以上、システムは「譲れない品質」というものを意識せざるえません。

ですが、テストという工程にはまだまだ「担当者任せ」という側面が色濃く残っている気がします。

つまり、手法については「命令網羅」「分岐網羅」「条件網羅」「同値クラス」「境界値」等を、テストの完了条件に設定すればある程度ルール化は可能ですが、「具体的にどういった値を用いるか」というテストの内容については、開発者が「不安だと感じる」ことに依存してしまっているのではないか、と思うです。

ここで「それを勉強しない開発者が怠慢」と考えるか「チーム全体で対策する」と考えるかは、そのチームの文化によるのかも知れませんが、個人的には前者だと事業として安定させるのが難しいようにも思いますし、バグが出た場合そのモジュールを作った人間が吊るし上げられる文化では、開発プロセスの改善を難しくするというデメリットの方が大きいと思います。
では後者は、というと率直に言って開発規約を設けるということなので、「ルールを無視する人」がいなければそこそこいけるんじゃないでしょうか。ただし、すべてにおいて無条件に適用出来れば良いのですが、それが難しいケースについては個別に何かを考えなくてはなりませんから、ここに「担当者任せ」という要素が入り込む可能性が出てしまいます。これをどうするか、という運用上の問題は残ります。

個人的には、多少のリスクがあろうとも後者を推したいですね。

先にあげた５つの手法は割と機械的に「用いる値」が決まってくるので、この５つの手法を活用する事を「チームの統一されたテスト方法」として定着させる、ということです。

モジュールの仕様によっては、条件網羅で組み合わせ爆発が起こるかも知れない心配があるので、ここには「15ポイントルール」を適用させるなりしないといけないかな、等と思いますが、これもテストのサイズを平均させるためと考えればさほどおかしな事ではないのかな、と。

でも、15ポイントルールをぶっちぎられた場合、どうしたら良いかは難しい問題ですね。
どうしましょう。