障害数を評価する

障害数の評価はどうやって行えば良いでしょうか。


障害密度の指標は一般的に気持ち高めに設定されていると思います。基本的に障害指標を超えてしまうと問題になるわけで平均値を指標にしてしまうと半分は問題のあるモジュールになってしまうからです。

障害数が障害密度より少ない場合


この場合、ある条件を前提とする限り問題ありません。その前提とはテストケース数がテスト密度を超えているということです。ケース数が少なくて障害数が少ない場合は単純にテストが足りていません。ケース数が多くて障害数が少ないのであればテストは網羅されているという前提になるのでいくら障害が少なくても問題にならないわけです。

障害数が障害密度より多い場合


障害数が指標を超えている場合は注意が必要です。上記にも書きましたが基本障害の指標は高めに設定されているはずなので少しでも多い場合は問題がある可能性が高いです。また、障害数がギリギリセーフくらいでもスキルが高くて普段障害を出さないような人が作成しているような場合も同様に注意する必要があります。ちなみにこちらもケース数は指標を超えている事が前提になります。


障害数が高い場合は実装が難しい部分であるか実装した人のスキルが低い場合です。あとは高機能なライブラリを使用しているような場合もたまにあります。


障害数が多い場合の基本的対策は追加レビューか強化テストです。


追加レビューは基本開発したソースをレビューすると思いますが、さらにそのソースを確認していないスキルのあるメンバーにソースをレビューしてもらいます。レビュアーを増やすわけですね。実装が難しい場合やスキルが低い人が作成したような場合は有効な手法です。


強化テストはさらにテストを追加する方法です。基本的に使用しているライブラリ自体をテストするようなことはしませんが、高機能なライブラリを使用しているような場合は実はそのライブラリ自体にバグを含んでいるような場合があります。発生している障害にライブラリのバグが含まれているような場合は、そのライブラリ自体もある程度正しく動作するか追加テストを実施する必要があります。


障害数が多くてもケース数と障害数の割合が指標と同等の場合はケースも多くこなしているので指標的には問題ない気もしますが、実装が難しい箇所ではないかどうかくらいは確認しておいた方が良いでしょう。


Next >> 指標に使うステップ数を数える方法


目次に戻る