いきなりテストケース表を作ってはいけない

厄介なことにソフトウェアは形がないため、定規で測ることもできないし、重量を計測することもできない。第一、そうした単位を持たせて設計することができない。

現実的にできそうなものはプログラムのコード、ステップ数やバイナリのサイズがあることにはあるが、作り方により変動するので基準値を決めることができない。

やはり、ソフトウェアはハードウェアのように計測して品質を確かめることはできない。

ソフトウェアは業務要件を実現するシステム要件のほかに非機能要件の性質を持つ。業務要件は業務そのものであり、その一部分若しくは全ての業務をITに置き換える。どのように置き換えるかはIT要件であり、IT要件を実現するのがシステム要件である。

機能そのものの働きではなく、機能全体としての動きは非機能要件として様々な切り口で要求される。

とするとき、ソフトウェアの品質を確かめるにはどうしたら良いのだろうか。

ついつい現場でやってしまいがちなことは、書いたコードのとおりのテスト仕様書を書いてしまうと言うものだ。それではソースをなぞっているだけで、システム要件を確かめることにならないし非機能要件を確かめていることにはならない。

ここからわかることは、テストケース表を作ってはいけないと言うことだ。やらなければならないことは、テストをデザインすることである。

ただ、そのデザインを表現する仕方がテストケース表であれば、それは作らなければならないが、テストケース表を作る義務がないなら不要である。

必要なのはテストのデザインを記したものである。