テスト消化曲線とバグ発生曲線の7パターン診断：山浦恒央の“くみこみ”な話（16）

今回は、Gompertz Curveによる「プロジェクトの問題点解析」について詳しく解説。あなたの開発現場はどのパターンに当てはまる？

[山浦恒央 東海大学 大学院 組込み技術研究科 准教授（工学博士），＠IT MONOist]

　前回のコラム「最もタチの悪いバグが潜むテストフェイズとは？」では、7つの「基本的な出荷基準」を挙げ、「5．長時間耐久テスト、過負荷テストを実施した」について解説しました。今回はその続きとして、「6．バグの発生が頭打ちになった」を紹介します。

　まずは、7つの基本的な出荷基準について再掲します。

1. 全機能をテストした　
   ブラックボックス／ホワイトボックス・テストで同値分割を実施した。
2. 境界条件をテストした　
   ブラックボックス／ホワイトボックス・テストの境界値分析を実施した。
3. 未実行コードがない　
   ホワイトボックス・テストのC0パス網羅を満足した。
4. エラー・ゲシング（Error Guessing）を実施した　
   バグを想定し、それを摘出するためのテスト項目を設計・実施した。
5. 長時間耐久テスト、過負荷テストを実施した　
   48時間の連続運転や、過負荷状態での稼働テストを実施した。
6. バグの発生が頭打ちになった　
   いわゆる「バグ摘出曲線」がフラットになった。
7. 未修正のバグが残っていない　
   摘出したバグは全件修正した。

　前回の「5．長時間耐久テスト、過負荷テストを実施した」の説明では、テスト項目の消化パターンやバグの発生傾向は「Gompertz Curve（ゴンペルツ曲線）」というS字曲線に近くなると述べました。今回は、Gompertz Curveをソフトウェア開発の現場でどのように使用しているのかを中心に、「6．バグの発生が頭打ちになった」の詳細を解説します。

Gompertz Curvによる品質制御

　Gompertz Curveを使って、ソフトウェアの品質制御やスケジュール管理を実施しているプロジェクトは非常に多いと思います。いろいろな国や企業で、さまざまなソフトウェアを開発していますが、Gompertz Curveの使い方は次のようなものでしょう。

（1）テスト項目の消化目標を設定する

　Gompertz Curveにうまく乗るように、テスト項目を消化する曲線を描きます（図1）。

図1　Gompertz Curveによるテスト項目の消化目標とバグ発生予測

　図1を見ると、線を引くのが大変そうですが、実際の開発現場では、「テスト項目の総数」と「テストに割り当てた日数」から適当に曲線を引いている場合がほとんどです。S字に曲げた針金の端を「テスト開始日＋テスト項目総数」に置き、もう一方の端を「テスト終了日＋テスト項目が0件」に置いて、針金を伸ばして決めるマネージャもいます。この後に述べる理由により、Gompertz Curveでの品質制御では、正確性や厳密性を求めませんので（すなわち、きちんと曲線を引いても意味がないので）、テキトーで構いません。

（2）バグの摘出予測をする

　テスト項目の消化目標曲線を描いたのと同様、Gompertz Curveに沿うよう、バグの発生曲線を引きます（同じく図1参照）。上記のテスト項目消化目標の曲線は、テスト項目の総数が分かっていますので簡単に描けますが、バグ摘出予測の曲線は摘出バグの累計が分からないため、少し苦労します。でも、この場合も、以下のような方法でテキトーに描いてください。

1．同じ構成メンバで過去に開発実績がある場合、そのときのバグ・データ（例えば、ソース・コード1000行当たりの発生バグ密度）を適用します。前回のバグ密度が6.37件／KLOCとし、今回の開発ステップ数が152KLOCとしますと、152×6.37＝968.24で約968件となります。

2．過去の開発のデータを収集していない場合や、新メンバによるまったく新しい分野のソフトウェア開発の場合、標準的な値として、5〜6件／KLOCの範囲でテキトーにバグ密度を設定します（これも、適当で構いません。こんなところで時間を食うべきではありません）。

（3）消化したテスト項目と摘出したバグの件数を図にプロットする

　テストを開始したら、毎日、消化したテスト項目数と摘出したバグの数を図にプロットしていきます（図2）。

図2　消化したテスト項目数と摘出したバグ数をプロット

　ここで注意すべきことは、「消化したテスト項目」は実行したテスト項目ではなく、“合格になったテスト項目”だということです。従って、バグを見つけたテスト項目は、バグを修正して正しい結果が出るまで、「消化したテスト項目」にはカウントしません。例えば、図2で1月5〜12日まで「未実施のテスト項目数（実際）」が水平になっていますが、これは摘出したバグを修正できていないため、テスト項目の消化が進んでいないことを示しています（そのバグにより「パイプが詰まった」状態です）。

（4）品質を予測する

　図2の「テスト項目消化の実際の数」と「摘出したバグの数」をベースにして、品質の予測（特にリリース予定日）や、プロジェクトの問題点を分析します。

数学嫌いのプログラマとGompertz Curve

　Gompertz Curveを表す数式は、極めて厳密で難解です。数式の詳細は前回のコラムに記しましたので、そちらを参照していただきたいのですが、ソフトウェアの品質制御で、この数式をそのまま使うことはまずありません。これには3つの理由があります。

　第1の理由は、ソフトウェア開発の分野は「数学が嫌いな理科系の吹きだまり」であり、ソフトウェア技術者はこんな複雑怪奇な数式を見ると即死するためです（ちょっと極端かもしれませんが、ソフトウェア開発に必要な数学は、加減乗除と集合論が主でしょう）。

　理由その2は、数式が難解過ぎて電卓では計算できないため、Gompertz Curveを処理するツールが市販されているためです。適当なパラメータを入れると、曲線を描いてくれ、実測データをいくつか入力すると、それに合ったGompertz Curveの式を求めてくれます。数学嫌いのプログラマにはぴったりのツールといえます。

　最後にして最大の理由は、図に「バグの摘出数」や「テスト項目の消化数」を正規化して、プロットすることが非常に難しいためです。常識的に考えると、1日に1人のプログラマが30分しかテストを実施しない日と、8人全員で18時間も必死にテストを実施する日を同じ「1日」として図の上にプロットするのでは、正確な予測はできません。では、どうすればいいか？ 例えば、2時間単位で消化したテスト項目、摘出したバグ数を集計してプロットすると、正確性、厳密性は飛躍的に向上します。しかし、テスト項目を必死につぶそうとしているプログラマに対し、「2時間ごとに、実行したテスト項目と見つけたバグの数を教えて」とお願いしても、きちんとカウントしてくれないでしょうし、面倒なのでイイかげんな数値を報告されてしまう可能性が大です。正規化して、Gompertz Curveにプロットしているプロジェクトは、ほとんどないと思われます。

　では、「イイかげんで不正確」なGompertz Curveをソフトウェアの開発現場でどのように使っているのか？ 主な使用法は「プロジェクトの問題点解析」と「リリース予定日の予測」の2つです。

Gompertz Curveによるプロジェクトの問題点解析

　ソフトウェア開発でGompertz Curveを使う場合、曲線のパターンや傾向を大ざっぱに分析して適用する場合がほとんどです。「消化したテスト項目数」と「摘出したバグの数」の曲線をチェックすると、いろいろなことが分かります。医者が体温と血圧を測って、患者の基本的な体調を予測するようなものです。

理想型

　図3-1が「理想のパターン」です。「消化したテスト項目数」と「摘出したバグの数」の実測値が予定の曲線におおむね合っています。

図3-1　理想型

　「理想」と「現実」には大きな差があります。ソフトウェア開発でも同様で、なかなか予定したGompertz Curveどおりにはいきません。「理想」と「現実」には差があり、以下に挙げる6つのパターンのいずれかになる可能性が大です。各パターンを示したプロジェクトで、何が起きているのかを分析してみましょう。

停滞型：テスト担当者の能力不足

図3-2　停滞型

　図3-2を見ると、テスト項目の消化が遅々として進まず、また、バグの摘出も芳しくありません。このような「停滞型」のパターンになる最大の原因は、テスト担当者の経験や能力不足です。開発部門に配属されて1週間の新人にテストを丸投げすると（新人にテストをさせるのは、50年前からのソフトウェア業界での「習慣」です）、テストの勝手が分からず、このようなパターンになります。

　テスト仕様書に実行手順がすべて明記してあるといっても、最低限の常識や経験がないと、効率の良いテストはできません。包丁を握ったこともない人が、レシピ本を横目で見ながら、「ブルゴーニュ風ビーフ・ストロガノフ」を作るようなものです。

　ただし、図3-2の問題は、それほど深刻ではありません。テスト担当の新人に、ベテラン技術者を2、3日張り付けると、テスト実行のコツをつかみ、図3-1の「理想のパターン」に戻ります。

疑似高品質型：本当にプログラムの品質が良いか？

図3-3　疑似高品質型

　図3-3のパターンでは、テスト項目を快調に消化し、バグもあまり出ていません。これには、2つの理由が考えられます。「テスト項目の品質が悪い」と「プログラムの品質が良い」です。

　バグを摘出する能力の低いテスト項目が多いと、テスト項目を大量に実行してもバグにヒットしないので、バグは見つかりません。いわゆる「低打率のテスト項目」であり、テスト項目の再設計や追加が必要になります。一方、テスト項目の品質が悪くない場合、プログラムの品質が良いことになります。

　このどちらに該当するかを見極めねばなりませんが、筆者の経験上、このパターンになった場合、「プログラムの品質が良い」ことは1回もありませんでした。このパターンは、まず「低打率」と見てよいでしょう。「低打率テスト項目」と「低品質プログラム」の両方が当てはまる場合もありますので、注意が必要です。

真正高品質型：プログラムの品質が良い

図3-4　真正高品質型

　図3-4では、テスト項目を予定以上のペースで消化している一方、バグの摘出数は予測値以下です。プログラムの品質が良い場合に見られる典型的なパターンであり、図3-3の違いに注意してください。

　これは、プロジェクト・マネージャには理想のパターンといえます。このパターンになると、プロジェクト・マネージャは、「今回は、大きなトラブルもなく順調に開発が進みそうだ。土日も出てこなくて済むし、うまくいけば毎日17時に帰れるかも……」と胸をなで下ろしながら、最善を夢見ますが、こんなパターンになる幸運は、まずあり得ません。安心し切っていると、途中でバグが大量に見つかり、「いつもの道」へ逆戻りする場合がほとんどです。

お祭り型：ベテランの急ぎ仕事

図3-5　お祭り型

　図3-5のパターンは、ちょっと変わった形をしています。テスト項目はスケジュールより早く消化できていて、バグは予定を上回って見つかっています。この派手な「お祭り状態」のパターンは、テスト項目の打率が高く、プログラムの品質が低いことを示しています。とはいえ、テスト項目が順調以上に消化できていることから、バグは単純なものがほとんどで、修正に時間はかかっていないと推測できます。

　熟練プログラマが急いで作ると、このパターンになります。現在、マシン上でテストしているのなら、一度机上テストへ戻って、単純なバグを効率よく摘出するのが解決の近道です。また、バグの傾向をチェックし、類似バグをたたき出すことも重要です。いずれにせよ、それほど深刻な状態ではありません。

バグだらけ型：最も普通のパターン

図3-6　バグだらけ型

　図3-6では、テスト項目の消化は予定どおりですが、バグは予測をはるかに超えて大量摘出されています。この「バグだらけ型」のパターンでは、デバッグ項目の品質は普通であり、プログラムの品質が悪いと考えられます。ソフトウェア開発で、最もよく見掛けるパターンがこれです。このパターンになると、プロジェクト・マネージャは「最悪の事態にはならないようだ。いつもどおり、しっかり残業すれば乗り切れるだろう」と考え、ホッとすることが多いと思います。

　この型が起きた場合、このままのテスト項目でテストを終了させ、その後に、バグの傾向や類似性を分析して、「バグの巣」を見つけるようなテスト項目を追加するとよいでしょう。「いつものパターン」なので、深刻さはありません。

深刻型：前フェイズの品質が低い

図3-7　深刻型の2パターン

　図3-7に示した2つは、テストフェイズで最も悪いパターンです。テスト項目の消化が難航しているのに、バグは順調に大量に出ています。このパターンの良くないところは、テスト項目の実施で非常に苦労していることです。すなわち、重要度の高いバグ、修正による影響が広範囲に及ぶバグ、仕様漏れ、根本的な処理方式の不良など、深刻なバグが多発し、バグ修正に時間がかかっています。

　この原因はただ1つ。要求仕様定義フェイズ、設計フェイズ、コーディング・フェイズという「前フェイズ」での品質が低いことが、このパターンになる最大の理由です。

　この状態になると、プロジェクト・マネージャの取るべき手段は2つしかありません。「品質の悪いソース・コードをだましだまし使う」と「すべてのソース・コードを捨て、設計し直す」の2つです。普通は、作ったものを捨てるのはもったいないと、いまはやりの「エコ感覚」で低品質プログラムからバグをたたき出して、高品質ソフトウェアを作りたくなります。でも、これではガラクタを寄せ集めた「廃物利用」であり、高品質プログラムは望むべくもありません。プログラムの保守性は極端に悪くなり、バグ修正時に新たなバグを作り込む可能性が極端に高くなります。米国のプログラマがいう「Garbage in, garbage out（ゴミを入れると、ゴミが出る：品質の悪いものからは品質の悪いものしかできない）」の状態です。こんなプロジェクトは、必ず泥沼状態になります。

　この「深刻型」になった場合は、潔くバグだらけのソース・コードを捨て、設計し直すのが、長期的な展望に立ったプロジェクト・マネージャとしての正しい戦略です。遅れても、数カ月です。設計し直しても「低品質プログラムをだましだまし使って完成させる」より、はるかに早く製品をリリースできます。

　以上が、Gompertz Curveによる「プロジェクトの問題点解析」です。次回は、バグ摘出曲線のパターンをベースにして、残存バグ数やリリース日を推定する方法を述べます。特に、Gompertz Curveを分析することにより、「6．バグの発生が頭打ちになった」の状態を摘出する方法を解説します。（次回に続く）

【 筆者紹介 】

山浦 恒央（やまうら つねお）
東海大学 大学院 組込み技術研究科 助教授（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科助教授、現在に至る。

主な著書・訳書は、「Advances in Computers」 （Academic Press社、共著）、「ピープルウエア 第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ 第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。