テスト報告書・信頼度成長曲線による潜在バグの推定
ソフトのテスト報告書には見つけられなかったバグの推定件数を書く
テスト報告書には信頼度成長曲線を使って、まだ見つけていないバグがどれ位残っているのかの、潜在バグ件数の推定を書きます。信頼度成長曲線とはバグ曲線の一種で他にはゴンベルツ曲線などもバグ曲線です。バグ曲線は色々な種類がありますが、どれもテストで見つかったバグの累計件数をプロットしたグラフに曲線を当てはめて、このままテストを続けたら後何件くらいのバグが見つかるかを推定します。
ソフトの品質を判断するためは、テストで見つけたバグだけではなくテストで見つけられなかったバグ＝まだソフトに潜在しているバグの情報も非常に重要です。まだ見つけていないバグなので何件あるかは判らないので、バグ曲線を使って、これまでに見つけたバグの状況から推定するします。
なぜ潜在しているバグの情報が重要なのか、すこし考えてみましょう。ソフトの品質の良し悪しをバグの観点から判断するならば、ソフトに残っているバグが少ない程品質が良いとなります。ソフトに残っているバグとは ①既に見つけたけども修正が間に合わなかった未修正のバグ と ②まだ見つけていないけどソフトに潜在するバグ の２種類です。①は件数も内容も判っていますが ②は見つかってないので件数も内容も不明です。不明なので、潜在バグはゼロ件かもしれないし、100件あるかも知れません。つまり潜在バグの状況が判らないと、ソフトの品質が良いか悪いか判らないという事になります。
ソフトの品質は潜在バグがどれだけあるかに掛かっている
ソフトの品質がリリースしても大丈夫なレベルまで良くなっているかどうかを確認するには、実はこの潜在バグが十分に少ない状況になっているかを確認する事が必要になります。そのために、十分な量と質のテストを実施してバグの洗い出しは十二分にできているか？とか、今回のバグの検出状況はこれまでの同様のソフト開発と比べて遜色はないか？とか、今回のテストの内容やその成果を元に、潜在バグが殆ど残っていない事を定性的に推定しようと試みます。
そして、潜在バが残っていない事を定量的に推定するため手段の１つが、信頼度成長曲線（SRGM: Software Reliability Growth Model) を使った潜在バグ数の推定です。 信頼度成長曲線を使う事で、潜在バグの件数やこれまでテストで見つけたバグが全てのバグの何％になるかの推定値を計算できるので、潜在バグの状況を定量的に「推定」する事ができます。
信頼度成長曲線はバグ曲線のひとつで今後のバグ数を推定する
信頼度成長曲線とは、横軸にテストの量（テスト項目数やテスト工数）をとり、縦軸に検出したバグの累計数をとった、Ｓ字カーブを描く事を想定した曲線です。（テストの初期段階ではＳ字カーブにならずに元気に立ち上がります・・・） バグの検出状況を見える化したグラフという意味でバグ曲線という一般名で呼ばれる事もありますし、同じようにＳ字カーブを描くゴンベルツ曲線やロジスティック曲線もバグ曲線に使われる事もあります。
信頼度成長曲線にしてもゴンベルツ曲線にしてもバグ曲線による潜在バグ推定の基本的な考え方は、①これまでのテスト実績（＝テスト量と検出バグ累計）をグラフ上にプロットして、②その実績値に沿うように曲線のカーブを当てはめて、③このままテストを続ければ曲線に沿った件数でバグが検出されるだろうと推定する といものです。
信頼度成長曲線の一例が下のグラフです。 赤でプロットした折れ線グラフ部分が ①テスト実績です、横軸が130 縦軸が42 の実績が最新です。この実績のプロットに ②当てはめた信頼度成長曲線が紫色の曲線です。そしてこの曲線の横軸が130から右側の部分が ③今後のテストで見つかるバグ件数の推定 です。この推定だと、テストを続けると48件程度までバグが見つかるだろうという見方になります。今までに見つけているバグが42件なので、あと6件バグがみつかるだろうという意味ですね。
上の例ではまだテストが十分に進んでいない状態の実績を元にしているので曲線が寝切っていません。まだ潜在バグが残っていると推定されるのでテストは続ける必要があります。この状態からさらにテストを続けてバグの検出の実績を増やした場合のテストのデータを元に信頼度成長曲線を書くとグラフは次のようになります。実績を示す赤いプロットの先に延びている紫の曲線の延長部分は、ほぼ水平に寝ていてこれ以上バグが見つからないという推定になっています。
信頼度成長曲線を書けば潜在バグの件数や現在何％のバグが検出できたかを数値化できる
信頼度成長曲線を書けば、その曲線の漸近線（曲線に限りなく近ずく線）のY軸値の値から、全バグ件数（＝テストで検出される全てのバグ件数）の推定値が判ります。全バグ件数の値から現時点で検出されたバグの件数を差し引けば、それが今後のテストで検出される可能性のある潜在バグの件数になります。 また、( これまでに検出されたバグ件数 X 100 ) /全バグ件数 を計算すると、現時点でのバグ検出率（＝これまでに検出したバグが全バグ件数の何％に相当するのか）が計算できます。
グータラ親父は、テストの実績（工数とバグ検出件数）を入力すると信頼度成長曲線を作成した上で、全バグ件数や現時点でのバグ検出率を計算してくれる、SRGM2 というソフトツールを使って、グラフの作成や全バグ件数・バグ検出率の算出をしていました。 このソフトツールは、指数型モデル、超指数型モデル、遅延S字型モデル、ゴンペルツ曲線、ロジスティック曲線、習熟S字形モデル をカバーして、入力した実績値を元に最適な曲線モデルを選び、そのグラフのパラメータを決定してグラフを作成してくれる物で、なかなか使い勝手は良かったです。
経験的には、バグの検出率が 95%～98% を超えてこないと、まだ潜在バグが残っていてそのバグが市場で問題を引き起こすリスクが高いので、ソフトのリリースは止めておいたほうが良い（もっとテストを続けてバグを出し切る）という感じでリリース判断の１つの指針に使っていました。
信頼度成長曲線の推定は信用できるのか
信頼度成長曲線を使った全バグ件数や潜在バグ件数やバグ検出率の推定値は、まだ起きていない未来これから実施するテストで検出されるバグの数を推定しているだけです。今後のバグの検出数が信頼度成長曲線に沿うというような理論的な証明がある訳ではないので、要するに当たるも八卦当たらぬも八卦の世界です。
それでも、別の記事にも書いていますが、ソフトの品質にとって非常に重要な潜在バグの件数を数値化して示す事ができて、品質の良し悪しの判断に使い易いというメリットと、多くの開発プロジェクトで実際に使って利用実績を蓄積してみると、それなりにソフトの品質との相関関係が良いという経験則とから、グータラ親父は信頼度成長曲線はそれなりに使い物になると考えて、リリース判定に使っていましした。
見つけられなかったバグについての考察も重要です
テスト報告書にはテストで見つけたバグについての分析は必須ですが、ソフトの品質の判断のための情報としてはまだ見つけていないバグについての推測もとても重要です。まだ見つけていないバグについて何が書けるのか、次の記事で紹介します。