プログラムの規模などから、どのくらいのテスト項目数が必要なのか、どのくらいバグが発見されるのか、といったことは、ある程度は想定できるかもしれない。
しかし、そうした量的な指標が有効なのは、開発するシステムの種類や特徴、プロジェクトチームのスキルなどが、安定している場合だけであろう。例えば、同じ開発メンバーが同じようなシステムを作る場合には、有効かもしれない。
逆に言えば、どんなプロジェクトにでも通用するような、量的基準を作ることは難しい。例えば、テスト項目数が基準値を満たしていても、テスト観点に抜け漏れがあれば、何の意味もない。
当たり前の話ではあるが、テスト工程の「品質」を正しく把握するためには「質的な」評価が必要である。
テストを行うに際に大切なのは、テスト項目の数ではない。テストの観点に偏りや抜け漏れがないか、ということである。それを確認するためには、テスト項目の内容を詳細にチェックしなければならない。
また、発生したバグについても、ただ件数を数えるだけではなく、内容まで分析しなければ意味がない。例えば、結合テストで10件のバグが見つかったとしよう。数字だけしか見なければ、ただそれだけの話である。しかし、内容まで調べれば、そのうち9件が「単体テストで見つけておくべきバグ」であることが分かったりする。このように、質的に意味のあるレベルまで分析しなければ、数値の意味はない。
量的な評価が、テスト項目の数を数えるだけでできるのに対し、質的な評価をするには、非常に多くの手間が掛かる。
しかし、だからといって、量的な指標を絶対視し、それだけでテストの品質を決めつけてよいというものではない。
管理者が恐れるべきは、「管理しているつもりになること」である。数値を測定し、表やグラフを作れば、なんとなく管理をしている気分になってしまう。しかし、質的に意味のない数値は、いくら集めても役に立たない。
そうした実のない管理方法が最悪の結果として現れるのは、抗いがたい権力をもって、開発者に「量的なノルマ」を課した時である。
前編 、中編 に書いたような弊害は、その例である。
ここで、「バグが出ないこと」に悩まされていたプロジェクトマネージャは、顧客に虚偽のバグ数を報告をすることもできたはずだ。それをさせなかったのは、彼の人としてのモラルである。
しかし、この顧客が必要以上に「バグ数の要求」を続けるならば、いつか誰かが虚偽の報告をしないともかぎらない。
バグ数を増やすために故意に品質を下げるくらいなら、嘘をついたほうがマシだと考える開発者は必ずいる。
開発者にとって、「品質を上げる」ということは、それほど重要なものなのである。
※単体テストはひとつの機能(部品)のみのテストで、結合テストは複数の機能を組み合わせたテスト。当然、それぞれのテストは「観点」が違う。結合テストは、単体テストの後に行う。
■関連記事
・バグを求めるものたち 前編
・バグを求めるものたち 中編
ソフトウェアテスト技法
―自動化、品質保証、そしてバグの未然防止のために
―自動化、品質保証、そしてバグの未然防止のために
posted with amazlet
on 06.05.06
ボーリス バイザー
日経BP出版センター (1994/02)
売り上げランキング: 27,689
日経BP出版センター (1994/02)
売り上げランキング: 27,689
おすすめ度の平均: ![5](https://img-proxy.blog-video.jp/images?url=http%3A%2F%2Fimages-jp.amazon.com%2Fimages%2FG%2F09%2Fx-locale%2Fcommon%2Fcustomer-reviews%2Fstars-5-0.gif)
![5](https://img-proxy.blog-video.jp/images?url=http%3A%2F%2Fimages-jp.amazon.com%2Fimages%2FG%2F09%2Fx-locale%2Fcommon%2Fcustomer-reviews%2Fstars-5-0.gif)
![5](https://img-proxy.blog-video.jp/images?url=http%3A%2F%2Fimages-jp.amazon.com%2Fimages%2FG%2F09%2Fx-locale%2Fcommon%2Fcustomer-reviews%2Fstars-5-0.gif)
![5](https://img-proxy.blog-video.jp/images?url=http%3A%2F%2Fimages-jp.amazon.com%2Fimages%2FG%2F09%2Fx-locale%2Fcommon%2Fcustomer-reviews%2Fstars-5-0.gif)
実践的ソフトウェア測定
posted with amazlet
on 06.05.06
John McGarry Cheryl Jones Elizabeth Clark David Card Beth Layman 古山 恒夫 富野 寿
構造計画研究所 (2004/07)
売り上げランキング: 60,076
構造計画研究所 (2004/07)
売り上げランキング: 60,076
おすすめ度の平均: ![4](https://img-proxy.blog-video.jp/images?url=http%3A%2F%2Fimages-jp.amazon.com%2Fimages%2FG%2F09%2Fx-locale%2Fcommon%2Fcustomer-reviews%2Fstars-4-0.gif)
![4](https://img-proxy.blog-video.jp/images?url=http%3A%2F%2Fimages-jp.amazon.com%2Fimages%2FG%2F09%2Fx-locale%2Fcommon%2Fcustomer-reviews%2Fstars-4-0.gif)
![4](https://img-proxy.blog-video.jp/images?url=http%3A%2F%2Fimages-jp.amazon.com%2Fimages%2FG%2F09%2Fx-locale%2Fcommon%2Fcustomer-reviews%2Fstars-4-0.gif)