信頼度成長曲線（バグ曲線）は３つの視点でソフトの品質を判断する
信頼度成長曲線は①潜在バグ数と②終盤の寝具合と③真ん中の立上がり具合を見る
ソフトのテストに関わっている人は、リリース判定やテストの終了判断の場面で、信頼度成長曲線（バグ曲線やゴンベルツ曲線）からソフトの品質の良し悪しを判断することも多いですね。では、信頼度成長曲線から何をどの様に読み取ってソフトの品質を判断すれば良いのでしょうか？
この記事では、グータラ親父のこれまでの経験を元に、信頼度成長曲線を読む時の視点を以下の３つに分けて紹介します。皆さんが信頼度成長曲線からソフトの品質の良し悪しを判断する時の参考になれば、幸いです。 なお、信頼度成長曲線がどんな物なのかは別の記事で紹介予定ですので、そちらもご覧ください。
視点１：残存バグの推定件数は十分に少ないか：既知の未修正バグと潜在バグの合計が十分少なくソフトのプロダクト品質が良いか
信頼度成長曲線（バグ曲線）で最初に見るのは潜在バグの推定件数です。潜在バグの推定件数は、信頼度成長曲線の漸近線が示す全バグ数の推定件数から、現時点で発見されたバグの総件数を引き算した値として求められます。ソフトのリリース判定やテスト終了判断で一番重要なのがソフトのプロダクト品質ですが、プロダクト品質の良し悪しを判断する重要な指標の１つがソフトに残存バグがどれだけ残っているかです。
ソフトの残存バグは、①テストで見つけたけれどもリリース時までに除去しきれなかった既知の未修正バグと、②リリースの時にはまだ見つかっていない潜在バグの２種類のバグの総和です。既知の未修正バグは件数が判りますが、潜在バグはまだ見つかっていないので何件あるのか判らないのでやっかいです。信頼度成長曲線を使うと、この潜在バグの件数を推定する事ができて残存バグの数が判るようになるので、ソフトのプロダクト品質の良し悪しの判断ができるようになります。
視点２：曲線の後半は滑らかで寝ているか：実施したテストはバグを検出する能力のある質の良いテストだったのか
信頼度成長曲線を見る時の２つ目の視点は曲線の後半が滑らかで寝ているかという定性的な視点です。この場合に見るのは、信頼度成長曲線で実績値がプロットされている部分の最後の部分です。この実績値の部分が滑らかで寝ているというのは、テストの後半でバグの検出が十分に少なくなるまでテストが継続されている事を示します。そしてそれは、よく考えられた質の良いテストが十分な量で実施されている事を示唆しています。
ソフトのバグはテストで検出されるのですが、極端な言い方をすれば、①テストをしなければバグは１件も見つかりませんし、②質の悪いテストではいくらテストをしてもバグは見つかりません。という事は、バグの件数からソフトのプロダクト品質を判断するためには、質の良いテストを十分な量で実施しているという前提が大切だという事です。テストしなけりゃバグはゼロ・バカなテストじゃはバグはゼロなのです。そして非常に大雑把な話になりますが、信頼度成長曲線の実績部分の後半 1/4 程度の曲線が滑らかで十分に寝ていると、質の良いテストが十分な量で実施されている場合が多いというのが、多くのソフト開発プロジェクトからの経験則です。
視点３：曲線が中央付近で綺麗に立ち上がっているか：テストの計画が妥当でテストの実施は順調だったのか
信頼度成長曲線を見る時の３つ目の視点は曲線の中央付近が綺麗に立ち上がっているかという定性的な視点です。この場合も見るのは、信頼度成長曲線で実績値がプロットされている部分です。この実績値の部分が綺麗に立ち上がっているというのは、テストの実施が順調だった事を示します。そしてそれは、テストの計画がテストの実施の順番も含めてよく考えられた質の良いテスト計画で、テスト対象のソフトもテストに耐えるだけの品質を持っているという事を示します。
一般的なテストの進捗状況では、テストを開始した初期にはテスト担当者がまだテスト対象や環境に不慣れだったり、テストの実施を阻害するようなバグが残っていたするため、投入した工数に対して実施されるテスト項目の数が少なくテスト効率が良くない場合が多いです。そのため、信頼度成長曲線の最初の部分の実績のグラフは曲線が寝ています。しかし、テスト期間の 1/4 から 1/3 を過ぎるころからは、テスト担当者も環境に慣れテストの阻害要因もデバッグで取り除かれてくるので、テストが一気に進み始めて信頼度成長曲線は立ち上がっていきます。ただしその様な様相を見せるのは、テストの順番がうまく考えられていて、ソフトの品質がテストを実施するのに耐える程度まで良い場合です。ですので、信頼度成長曲線が綺麗に立ち上がっているのなら、テスト計画が妥当でテストの実施が順調だったこと、つまりテスト対象のソフトもテストに耐えるだけの品質を最初から持っていた事を示します。
それでは、これらの３つの視点について以下でもう少し詳しく説明します。
視点１：残存バグの推定件数は十分に少ないか
信頼度成長曲線はテストで見つかったバグ件数の実績グラフにS字カーブを描く曲線を当て嵌めたものです。ですので、S字カーブには実績のプロットと重なる部分（実績部分）と、実績のプロットがなく曲線だけの部分（推定部分）があります。この推定部分は、今後テストを続けていけば、この様な期間にこのような件数のバグが見つかるだろうという推定を示しています。
そして、それなりの品質のソフトウエアに対して妥当な質と量のテストを実施していれば、S字カーブの最後の部分はほぼ水平に寝ていくという経験則があります。信頼度成長曲線が寝るという事は、バグがもうそれ以上は見つからないという事なので、S字カーブの漸近線の値がそのソフトウエアに存在していた全てのバグの件数だと推定する事ができます。
ソフトウエアに存在する全てのバグの件数が推定できれば、その値から現在までに検出したバグの総数を引き算すれば、まだ見つかっていない未検出の潜在バグの推定件数が求まります。これが、信頼度成長曲線を使った未検出の潜在バグ件数の推定の考え方です。
信頼度成長曲線を作成するツールには様々な物がありますが、この記事に載せているツールでは、ツーこの未検出の潜在バグの件数を数値として表示してくれています。このように数字で表示されていなくても、グラフの漸近線からでも、潜在する残存バグの件数を推定する事はできます。
なお、ソフトウエアのリリース時に、残存バグ＝検出済みの未修正バグ＋未検出の潜在バグを推定して、その推定値を元に定量的にリリースの可否を判断するという手法もあり得ます。その場合には、リリース時の未修正バグや未検出の潜在バグを何件まで許容するのか？、と大きな課題がでてきます。しかしこれは、製品やマーケットの求める品質レベルによって大きく変わってくるので、これまでにリリースしてきたソフトウエアの状況を見て、自社の製品にとって妥当な値を決めるしか、良い方法はありません。
視点２：曲線の実績部分の後半は滑らかで寝ているか
ある程度品質の良いソフトウエアを、よく考えられたテスト計画に沿ってテストすると、テストの最終段階ではテスト作業は進んでも新たなバグが殆ど見つからない状況になります。その結果、信頼度成長曲線の実績の最終部分は曲線が滑らかで寝てきます。
よく考えられたテスト計画では、テストの前半に単純なテストを集めます。単純なテストとは、テストの条件が１つか２つのテストとか、正常系の機能確認テストとかです。そしてテストの後半には安定性や堅牢性を確認するための複雑で手間暇の掛かるテストをも持ってきます。これは、テストとデバッグの作業を効率良く進めるための工夫です。
テスト対象のソフトウエアが非常に品質が良くてテスト項目の殆どが一発で合格するならば、どんな順番でテストを実施してもテストに掛かる期間は変わりません。でも実際には、テスト初期のソフトウエアはそこまでは品質が良くない場合が殆どです。そのために、テスト項目には無関係の別のバグのためにテストの前提条件が満たせなくて、目的のテストが実施が出来ないうようなテストブロッカーのバグが残っていたり、半日程度動作させていると性能が低下するなど安定性に問題が残っていたりします。そのような状態で複雑で手間のかかるテストを実行しようとしても、テストがうまく実施できない場合が多いです。
ですので、まずは簡単なテストを最初にもってきて、ある程度のバグを洗い出してデバッグサイクルを回して、テスト対象のソフトウエアの品質を十分に安定させてから、過負荷エージングや競合動作などの安定性や堅牢性を確認する複雑で手間暇の掛かるテストを行うようなテスト計画を立てる事で、テストの実施効率の改善を図ります。
そのようなテスト計画の元で、デバッグサイクルで十分バグを取り除き品質が向上したソフトウエアをテストしている場合には、安定性や堅牢性のテストを実施する段階では新たに検出されるバグの件数も少なくなり、結果として信頼度成長曲線の実績部分の終盤は滑らかで寝てきます。
逆の見方をすると、信頼度成長曲線の実績部分の終盤が寝ていないなら、それはテスト終盤でまだダラダラと新規のバグが見つかっている事を示しますし、終盤がデコボコしているのなら堅牢性や安定性のテストで散発的にバグが見つかっている事を示します。これらの事は、まだ十分にソフトの品質が高まっていない事を示唆します。
視点３：曲線の実績部分が中央付近で綺麗に立ち上がっているか
ある程度品質の良いソフトウエアを、よく考えられたテスト計画に沿ってテストすると、テストの中間の段階ではテスト作業が順調に進み、それに従って多くのバグが検出されます。その結果、信頼度成長曲線の実績部分が綺麗に立ち上がってきます。
よく考えられたテスト計画であっても、テスト対象のソフトウエアの品質が良くないと、テストブロッカーのバグが数多く残っていてテストがなかなか進まなかったり、検出したバグの修正版ソフトがリリースされて、前回不合格だったテスト項目を再テストをしたりという作業が増えてきます。 その結果、テスト工数やテスト項目数に対して発見したバグの件数があまり増えなかったり、修正案のソフトのリリース後に急にバグの発見数が増えたりします。 その結果、グラフの実績部分がデコボコしてきて、綺麗な立ち上がりになりません。
信頼度成長曲線は多くの場合、結合テストやシステムテスト以降のテストで発見されたバグの件数を数えてグラスを作成します。信頼度成長曲線の実績部分の中央付近が綺麗に立ち上がっていない場合は、上記のようにテストの最初の段階でソフトウエアの品質が不足していた事を示唆しているので、言い換えるとコーディングやと単体テストの段階でのバグ除去が不十分だったという事になります。
結合テストやシステムテストはソフトウエアの品質を保証する重要なプロセスですが、コーディングや単体テストで除去できるバグが十分に取り除かれている事が大前提です。コーディングや単体テストでのバグ除去が不十分で、バグが大量に埋め込まれたソフトウエアでは、いくら結合テストやシステムテストでバグを検出して修正する努力をしても、潜在バグを見落としてしまうリスクが高くなります。
このような見方をすると、信頼度成長曲線の実績部分の中央付近が綺麗に立ち上がっていない場合には、コーディングや単体テストでのバグ除去が不十分だった可能性が高く、その後の結合テストやシステムテストでも見落としているバグが潜在しているリスクがあるので、リリース判定には注意が必要です。