【バグ曲線〜何度目かの…】なぜ収束するのか

ソフトウェアテストシンポジウムJaast Tokyo'13で「なぜバグ曲線は収束するのか～Microsoft Excelを使って考えてみる～」（丹羽）という発表があった。
その場にいたし、当日発表資料と論文が以下に公開されているのでこれについて書いてみる。
 http://www.jasst.jp/symposium/jasst13tokyo/report.html 

この発表の論旨は、つまるところ、

テストケース中にどうしても含まれるテスト確認項目の重複と、バグを早く出そうというテスト実施者の恣意によるテスト実施順の２つが原因となってバグを前倒しで叩き出すことでいわゆるバグ曲線はあの形になる

と言っている。

言っていることは理解できる。

ただし、この２つの要因だけで、たくさんの事例で見られるあの曲線が本当に生まれるのかは、今回の説明だけでは分からない。
収束に寄与しうるということが分かっただけである。
これは発表においても言及されている。

だから本当はここで説明されていない別な要因があって、その寄与の方が大きく、今回の２つはあまり収束に関係ないという可能性は残ったままである。

まあ、そうではあるが、バグ曲線の収束理由について、あまり考えずに活用している組織が多いのは、そうであろうし、この理由について考えるべきと問題提起した意義はある。

しかし、論文も発表も同じであるが、その構成はよくない。

この発表では、結局、上の２つの理由からテストケースを用いたテストのバグ曲線管理は非常に難しい、というか、実質無意味に近いということを言外に言っている（ように見える）。

それはそれで、まあ良い。

とはいえ、最後の最後にテストケースに縛られないベータテストや運用テストでは、この２つの束縛から自由なのでバグ曲線管理はうまく行くのではないかみたいなことをさらっと言っている。

これは酷い。
現状高々５枚半の論文なのだから、このテストケースに縛られないテストにおけるバグ曲線の性質について述べるスペースは十分残っている。

これについて説明しなかったのは出し惜しみと言われてもしかたがない。。

そうは言いながら、発表資料にもあるが、バグ曲線の活用について、ここで示された収束理由を元に、品質担当者、開発者、上位マネージャー、そしてバグ曲線を納品条件にするお客様と議論してみることは良いことなのではないだろうか。

このような管理を生業とする人たちの好きなExcelを使って…という提案は良いと思う。
本論文ではそのために、採り上げた２つのバグ曲線収束理由の説明をExcel関数を用いているのだという。