リリース判定基準・潜在バグは何件残っているかを推定する
ソフトの品質は潜在バグの数で決まる
ここまでは、テストで見つけた既存バグについて、書いてきました。ところで、リリース判定の時に確認する必要のあるソースコードの品質の良し悪しをバグの数や内容で判断する時に一番大事なのは何でしょう？ 何か忘れているような気がしますね。。。そうです、ソフトの品質を判定するには、テストで見つけたバグではなくてまだテストで見つけられていない潜在しているバグがどれだけ残っているのか？ が、実は一番大切な事なのです。
ソフトウエアに潜在バグが１つも残っていなければ、品質は100点満点です。 でも、残念ながらどれだけ設計レビューやテストを行っても、潜在しているバグがゼロだという事を証明する事はできません。 まだ発見されていない潜在バグが何件あるかは、誰にも判らないからです。 見つけていない物を1件２件と数える事は、誰にもできません。
潜在バグはまだ見つかっていなので推定するしか手は無い
じゃ～今まで考えてきた事は何になるの？ という気もしますね。 実は、これまで考えてきた活動は全て、まだ見つけていない潜在バグが何件あるかを推定するための情報の収集なのです。 まだ見つけていない潜在バグが、本当のところあと何件あるのかは、誰にも判りません。
私たちにできる事は、既に見つけたバグは何件で、それはどんなテストで見つけて、そのテストの量と質はどんなもので、という情報をできるだけ多く集めて、集めた情報を色々な過去の経験と突き合わせて、もう十分にバグを見つけたのでまだ見つけていない潜在バグはきっと殆ど無いだろうなと、推定する事なのです。
そうして潜在バグが殆ど残っていない事を信じる事が出来てはじめて、そのソフトウエアをリリースしても良いと判断ができます。
潜在バグについてもう少説得力のある説明方法がほしい
でもこれだけだと要するに、頑張って一杯テストをしたのでもうバグ残ってないはずです、というだけなのでなにか説得力に欠けますね。 まあ、ソフトウエアのリリースを判定する時には、説得力はそれ程必要無いので問題では無いのですが。
しかし、対外的に品質状況を説明する時とか、社内の経営層に品質状況を説明する時とかには、もう少しカッコいい、何か理論的に見える、潜在バグはもう殆ど残って無いのですと言えるような方法が欲しいところです。
そしてそのような時に使える便利な方法が、昔からあるバグ曲線です。 バグ成長曲線とか信頼度成長曲線とか、ゴンベルツ曲線とかロジスティック曲線とか、いろいろな名前で呼ばれる事がありますので、皆さんも一度は聞いた事があると思います。
ソフトウエアのテストの終了判定（もう充分にテストをしたからこれでテストを終わってもいいですか？、の判定）に使うツールとして紹介される事も多いですね。 こんな、Ｓ字の形をした曲線です、皆さんも見 たことがあると思います。この記事では、バグ成長曲線という名称を使って説明をしていきます。
ゴンベルツ曲線/ロジスティック曲線
バグ成長曲線って何？
先ほどのグラフは、青線がゴンベルツ曲線で赤線がロジスティック曲線と書いてあります。 でもこれだでけでは、潜在バグがどれだけ残っているかの判定にどう使うか、判らないですね。 その前に少し言葉の関係を整理しておきましょう。
ゴンベルツ曲線とかロジスティック曲線とかは、グラフに描くとＳ字カーブを描く数学的な関数のゴンベルツ関数とかロジスティック関数とかで描いた曲線という意味でつけられた呼び名です。
一方で生物の個体数やソフトをてうとした時のバグ発見数など、最初は増えるのが遅くて、途中で急激に増えて最後はまた増加が少なくなるような増加の仕方をします。 その増加の状況を時間を横軸にして累積量を縦軸にしてグラフにするとＳ字を描くグラフになります。これを成長曲線といいます。
もう少し具体的にいうと、横軸をテストの量（テストの件数とかテスト作業の工数とか）にして、縦軸に発見されたバグの累積件数をとったグラフを描いた場合に、これをバグ成長曲線とか信頼度成長曲線と呼びます。 バグ成長曲線は略してバグ曲線と呼ぶ事もあります。 信頼度という言葉は、バグが少ない程ソフトウエアの信頼度が高いとの考えから、バグの件数の事を信頼度と一般的な言葉に置き換えたと考えて下さい。
そして、ソフトエアのバグ成長曲線は、経験上ゴンベルツ曲線やロジスティック曲線によく重なるという事が、多くのソフトウエア開発プロジェクトの観測結果から示されています。なぜそうなるのか、理論は判らないのですが、多くの経験からそのように判断しても間違いなかろう、という先人の知恵です。
そこで、実績値を元に描いたバグ成長曲線に重ねて、ゴンベルツ曲線やロジスティック曲線を描く事がよくあります。 なぜそんな事をするのはは、この後に説明しますね。
整理すると、バグ曲線も信頼度成長曲線も、成長曲線の１種にあたります。 この成長曲線はゴンベルツ曲線やロジスティック曲線とよく重なります。 ですので、バグ曲線や信頼度成長曲線を実績値を元に描いた時に、実績値に併記してゴンベルツ曲線が描かれる事があり、その時には全体としてゴンベルツ曲線と呼ばれる事もあります。 併記する曲線がロジスティック曲線であれば、全体としてロジスティック曲線と呼ばれる事もあります。
判ったような判らないような・・・
はい、なんかもや～としてますね、昔の人なら狐に騙されたような、、、とでも表現するのでしょうか。 では、もう少し具体例を使って見てみましょう。 これは、グータラ親父が使っていた信頼度成長曲線を描いてくれるソフトウエアツールの出力画面です。
信頼度成長曲線生成ツール
日々のテスト工数（人日）と検出したバグ件数を入力すると、横軸がテスト工数で縦軸がバグ累積件数になっている成長曲線をグラフとして表示してくれます。
グラフの赤い点が実際に入力した実績値で、紫の曲線が実績の赤い点に成長度曲線を当て嵌めたグラフです。 つまり、ゴンベルツ関数とかロジスティック関数などの数学的な関数を、実績の値に沿う様に関数の各種パラメータを調整して、カーブを当て嵌めたのが紫の曲線です。
で、信頼度成長曲線から何をどう読み取るの？
このグラフから、何が判るのでしょうか？ 赤い実績の値の一番右の端が、今の時点の最新状況です。 このグラフの場合は、テスト工数で130（人日）でバグの累計件数は42件です。 ここまでは、単なる実績値なので信頼度成長曲線なんて無くても事実として判っている事です。
では、実績の赤い点の途切れたさらに右側、今の最新状況よりも未来の部分は何を示しているのでしょうか。 例えばテスト工数が200（人日）のあたりでは、バグの累積数は47件でグラフはだいぶ水平にねてきています。 テスト工数が250(人日）あたりではバグの累積件数は48件で曲線は殆ど水平になっているので、これ以上バグが見つかる事はなさそうです。
この、最新状況より右の部分は、実績値に成長曲線を当て嵌めるとこうなるだろうという値です。 ソフトウエアのバグ成長曲線が、ゴンベルツ曲線やロジスティック曲線などによく重なるので、実績値より右の未来の部分のバグの検出数は、たぶんこの曲線に重なるだろう、と推定しているわけです。
推定の結果、テスト工数が 250（人日）に到達するまでテストをすれば、見つけられるバグは全部見つけ終わったと考えられます。 つまり、そこでテストを終わっても良いと判断できますね。 テスト工数が 200(人日）の時点では、まだもう１件のバグが見つかるかもしれません。 テストには費用も時間も掛かるので、テストを続けるかここで止めるか、判断は難しい時期ですね。
また、別の視点でこのグラフを見る事もできます。 今の最新状況で見つけているバグは 42件ですが、このままテストを続ければあと6件のまだ見つかっていない潜在バグが見つかるだろうという事も推定できます。 つまり、今のソフトウエアには、まだ見つかっていない潜在バグが6件あるだろうという推定ができます。
信頼度成長曲線は信用できるのでしょうか？
なんとなくそれらしい事を書いてきましたが、そもそも信頼度成長曲線を使った潜在バグの推定は信用できるものなのでしょうか？ 残念ながら信用出来るという証明はどこにもありません。 証明はどこにもありませんが、グータラ親父は長年に渡ってこの信頼度成長曲線をソフトのリリース判定の情報として使ってきました。次の記事では、なぜ信頼度成長曲線を使ってきたのか、グータラ親父の考えを紹介します。