バグ発生摘出率の収束

  • 投稿日:
  • by



バグが出なくなったらOK。


本当でしょうか。


バグ発生率を縦軸に、日付を横軸にしたグラフを書いて安心していませんか?


バグがたくさん摘出され、まともにテスト計画が遂行できないひどい状態になると、バグ摘出が止まることがあります。


バグのせいで、テストが進まないのです。なぜか?


バグが出るとテスターさん、テスト担当者さんは、バグをレポートにまとめる仕事に追われます。再現性が低ければ自分で追試を計画して実施しなければなりません。


バグレポートを書いたり、バグトラッキングシステムに登録したり、バグ管理票に記入したりしなければなりません。


それを上司がチェックし、誤字脱字の修正や、表現のレビュー反映など、多数の作業に追われます。実装者と同じなのです。


なのでバグが1件見つかると、テスターの手は確実に止まります。



バグ摘出率は、テストの消化項目数を分母にするか、テスト消化率そのものを分母にしてしまわないといけません。


しかしそれではテストの進捗にばらつきがあると、摘出率にもバラツキが出ているように見えてしまいます。


揺らぎですね。



開発者が自分でテストする自作自演の場合は、ここに書いた現象がもっと顕著です。


はっきりいって、そんな摘出率はどうでも良いので、積算のバグ摘出数をカウントするだけでよいと思うのは私だけでしょうか。



率にこだわわると真理から遠のく場合もあるということです。失業率と同じです。


ハローワークに通わない失業者は失業者としてカウントされません。


ハローワークの窓口の処理能力には限界がありますから、一時期に大量に失業者が発生すると、



失業率が改善する



というわけのわからない状況が生まれます。先月くらいから日本はそうなっています。


そんな指標に意味があるでしょうか。


なお、この議論は20年以上前から繰り返されています。変ったのは職業安定所という名前がハローワークになったくらいで、本質的には何も変っていません。



とにかくテストについてはJaSSTの発表資料くらいは目を通すべきです。


JaSSTソフトウェアテストシンポジウム


http://www.jasst.jp/




ソフトウェアテスト293の鉄則

ソフトウェアテスト293の鉄則