Web2.0時代のバグ管理ツールを作る（第3回）バグ成長曲線をどこまで信じればよいのか

不具合の状況を把握するツールのひとつに「バグ成長曲線」がある。これはテスト期間中に累計で何件のバグが検出されたかと、何件のバグが修正されたかを線グラフで表したもの。
（サンプルグラフ）

グラフの読み方は、
・テスト期間初期は基本機能テストやテスターの不慣れでバグがあまり出ない
・テスト期間中期は複雑な機能のテストを行うのでバグがたくさん出る
・テスト期間後期はバグが出尽くすのでバグがあまり出ない
つまり、グラフが山を作って水平になってきたら高品質確保、出荷OK、ということ。
バクテリアが増殖する時に、一定期間で増殖が飽和する曲線と似てます。

実はこれがクセ者で、
・テストをがんばってもなかなかグラフが寝ない
・意図的にグラフを寝せて品質が確保されたようにするのが簡単
という大きな矛盾をはらんでいたりする。

テストをがんばってもなかなかグラフが寝ない
テストを続ければ続けるほど、警告ダイアログの言い回しやOKボタンの位置などの細かい問題が出続けたり、複雑な手順や微妙なタイミングによる問題が出続けて、グラフが一向に収束する気配が無い。

意図的にグラフを寝せて品質が確保されたようにするのが簡単
テスト期間(日付）を軸にグラフを書いた場合、テスト実行数を減らすと不具合検出数が減るのであたかもバグが出なくなったように見える。こう書くとあたりまえなのだが、日付を軸にバグ曲線を書いているチームは多い気がする。
ただ、この件はテスト実施件数を軸にとれば回避できる。
この辺についてはソフトウェア・テスト PRESS Vol.1に詳しい。

一番の問題は
不具合の一件一件は重みが違う、ということ。バグ成長曲線上では、人が死ぬ可能性がある超A級問題と、誤字等のC級の問題が同じ1件としてカウントされてしまう。バグ成長曲線だけでシステムの安定度を予測するのはちょっと乱暴。

結論
・不具合件数だけでなく、もっと複合的な要素で判断すべき
・システムの状態を任意の軸に沿って総合的に把握できる仕組みが必要

そしてこの話題、次回以降に続きます。
(事情により、一部予定を変更してお送りしています。)
・これまでのツールの問題は[2006-02-26-1]
・エクセルでのバグ管理はなぜ駄目なのか[2006-02-27-1]
・バグ成長曲線をどこまで信じればよいのか[2006-03-27-1]
・バグ管理ツールの問題に対する一つの回答
・新ツールの画面イメージ
・各機能の説明

permlink