テストでの「ダメな猫」「普通の猫」「優秀な猫」：山浦恒央の“くみこみ”な話（17）
今回はGompertz Curveをベースに、一体どうなれば「バグの発生が頭打ちになった」といえるのか？ について詳しく解説する！
前回のコラム「テスト消化曲線とバグ発生曲線の7パターン診断」では、7つの「基本的な出荷基準」を挙げ、「6．バグの発生が頭打ちになった」について解説しました。今回はその続きを紹介します。
まずは、7つの基本的な出荷基準について再掲します。
- 全機能をテストした
ブラックボックス／ホワイトボックス・テストで同値分割を実施した。 - 境界条件をテストした
ブラックボックス／ホワイトボックス・テストの境界値分析を実施した。 - 未実行コードがない
ホワイトボックス・テストのC0パス網羅を満足した。 - エラー・ゲシング（Error Guessing）を実施した
バグを想定し、それを摘出するためのテスト項目を設計・実施した。 - 長時間耐久テスト、過負荷テストを実施した
48時間の連続運転や、過負荷状態での稼働テストを実施した。 - バグの発生が頭打ちになった
いわゆる「バグ摘出曲線」がフラットになった。 - 未修正のバグが残っていない
摘出したバグは全件修正した。
前回、「6．バグの発生が頭打ちになった」の説明では、「Gompertz Curve（ゴンペルツ曲線）」というS字曲線のパターンをテスト・フェイズでどのように解析して、ソフトウェア開発プロジェクトの現状の“健康診断”をしているのかについて述べました。今回は、同じくGompertz Curveをベースにして、具体的にどのような現象になれば「6．バグの発生が頭打ちになった」といえるのかについて解説します。
「バグの発生が頭打ちになった」の第1の意味
以前、Gompertz Curveについて説明したとき、Gompertz Curve自体は非常に精密な曲線であると書きました。しかし、入力となる「バグの発生状況」や「テスト項目の消化状況」のデータは非常にいいかげんな要素が多く、1日に1人で30分しかテストしていなくても、20人が18時間も必死になってコンピュータに張り付いてテストしても、Gompertz Curve上は、同じ「1日」と見なされるので、厳密さを期待してはならないと解説しました。もちろん、正規化すればいいのですが、そのための多大な労力を考えると、誰もが二の足を踏んでしまいます。
通常は、Gompertz Curveを正確に解析するのではなく、予想の曲線と現状の曲線がどのように乖離（かいり）しているのかをパターンとしてチェックし、プロジェクトの健康診断をする場合がほとんどです。通常、予想と現実は7つのパターンになり、このパターンを前回解説しました。
今回は「バグの発生が頭打ちになった」の意味について考えてみます。常識的には、“頭打ち”ということは、「バグ発生のGompertz Curveが水平になった」ということですが、ここで図1-1と図1-2を見てください。図1-1は、バグ発生曲線がなだらかに水平に近づき、最終的にはフラットになっています。一方、図1-2では、急激に発生していたバグが、ある日突然、摘出されなくなり、発生曲線が一挙に水平になっています。
もし、自分のプロジェクトのバグ発生曲線が図1-1のパターンであれば、非常に良い傾向であり、開発中のソフトウェア品質は順調に上がっています。これが「バグの発生が頭打ちになった」ということの第1の意味です。とにかく第1義的な意味であり、表向き、表面的ではありますが（本質的な意味、さらに重要なことは後述します）、まずはこれを満足させないと、品質制御は進みません。
一方、図1-2もバグ発生は“頭打ち”になっていますが、このパターンであれば、まだまだ品質は安定しておらず、深刻な問題が大量に隠れています。筆者は、過去三十年以上、国内外を問わずいろいろなバグ発生パターンを見てきました。合計は千を超えると思います。その中で、図1-2のパターンも数多くありましたが、このパターンのソフトウェアで高品質なものは1つもありませんでした。すなわち、この時点で、バグが収束しているように見えているだけにすぎません。
猛烈な勢いで発生していたバグが、ある瞬間からゼロになることは絶対に、絶対に、絶対にありません。台風一過の10分後には透き通るような青空が広がることはあり得ますが、ソフトウェア開発ではそんな現象は絶対に、絶対に、絶対にあり得ません。
もし、自分のプロジェクトで、図1-2のようなパターンになったとしたら、以下の原因が考えられます。
（1）単にテストを実行していない
図1-2の原因のほとんどがこれです。当たり前ですが、テスト項目を実行しないと、バグは出ません。この場合、テスト項目を実施していないので、「テスト項目消化曲線」が水平になっているはずです。しっかり、テストを続行しましょう。
（2）テスト項目の品質がかなり低い
テスト項目消化曲線が順調に下降しているのに、「発生バグ数」が水平になっている場合、テスト項目が簡単過ぎて、バグを摘出できていない可能性が大です。目前に大学受験を控えた高校3年生に、小学1年生用の四則演算問題を出しても、全問正解されてしまいます。テストの最終フェイズでは、ソフトウェアの品質もかなり上がっており、少々意地悪なテスト項目はウマくさばいてしまいます。図1-2のパターンになった場合、豊富なテスト経験を持った技術者に、テスト項目の内容をチェックしてもらうことが重要です。
（3）テスト項目が抜けている
図1-2のパターンになるケースで、テスト項目に起因するものとして「テスト項目が抜けている」が挙げられます。ある機能に対するテストがスッポリ漏れている場合もありますし、過負荷テスト、性能限界テストなど、いわゆる、「キツいテスト」が実施されていない可能性も大きいといえます（いずれにせよ、この抜けは致命的です）。ベテランの技術者がテスト項目の過不足、妥当性をもう一度チェックする必要があります。
どの原因にせよ、図1-2のパターンは品質制御上、非常に重大な問題を抱えており、早急、かつ、的確な対策が必要です。
「バグの発生が頭打ちになった」の本当の意味
先ほど「バグの発生が徐々になだらかになり、最終的に水平になる」ことは、「バグの発生が頭打ちになった」ことの第1義的なものにすぎない、さらに、“重要なこと”があると書きました。この「さらに重要なこと」とは、類似バグの検出です。
有名な3匹の猫の話として、「ダメ猫は、そこにいてもネズミが出てくる。普通の猫は、そこにいればネズミは出てこない。優秀な猫は、そこにいなくてもネズミは出ない」というのがあります。テスト項目を実行していてバグに突き当たり、このバグを修正する。これは、ソフトウェア技術者なら誰でも実行するごく当たり前のことであり、「普通の猫」です。では、「優秀な猫」はどうするのか？ 摘出したバグをじっくりチェックし、以下のように、技術的、心理的に分析して、類似バグ、同件不良をたたき出すのです。
（1）技術的な分析
なぜ、勘違いしたかの技術的要因を探ります。ビットの意味を間違えていたり、データ・サイズを誤解していたりなど、いろいろな原因があります。ほかの場所で、それと同じ間違いをしていないか、チェックする必要があります。
（2）心理的な分析
時間がなくて焦ってバグを作り込んだのか、時間がタップリあったのに間違えたのかですが、やっつけ仕事でバグを作ることはよくありますし、自然なことですが、熟慮のうえの間違いなら、事態は深刻です。何らかの抜本的な見直しが必要です。
「優秀な猫」は、1件バグを摘出すると、7〜12件の類似不良を見直すといわれています。この類似バグも含めて、バグの発生が水平になった場合、本当の意味で「バグの発生が頭打ちになった」といえるのです。
バグの重要度と「バグの発生が頭打ちになった」の関係
バグ発生のGompertz Curveが水平になっても、簡単には喜べません。テスト項目を実施して、それが摘出したバグの発生件数が頭打ちになっただけでなく、類似バグ分析で見つけたバグも収束しなければ、本当の意味で、「バグの発生が頭打ちになった」とはいえないからです。
「バグの発生が頭打ちになった」ことを分析するうえで、もう1つ重要なことがあります。それは、発生したバグの重要度です。テスト・フェイズの最終段階（アメリカ人技術者のいう「エンド・ゲーム」）に入り、バグの発生がなだらかになったとしても、見つかったバグが、データベース破壊、無応答、システム・クラッシュのような超重要バグばかりだと、まだまだ収束には程遠い状況です。
バグの重要度を「重大」「通常」「軽微」の3つに分類しますと、「通常のバグ」の件数は「重大なバグ」の10〜20倍、「軽微なバグ」は同様に「通常のバグ」の件数の10〜20倍発生するといわれています。テストの終盤では、以下のチェックが必要です。
（1）バグ全体の重要度分析
これまで摘出したすべてのバグの重要度をチェックし、重大、通常、軽微が常識的な配分になっているかを分析します。なっていなければ、それを説明できる理由があるかどうかをチェックする必要があります。
（2）最終フェイズのバグの重要度分析
最終フェイズで出たバグの重要度をチェックし、極端に「重大バグ」が多くないかを分析します。重大バグが多いと、まだまだ重大バグが隠れている可能性は大きいでしょう。図1-2でも示しましたが、ある日突然、事態が急激に好転することは、ソフトウェアの品質に限っては、絶対に、絶対に、絶対にあり得ません。
欧米に「自然は『真空』を嫌う（Nature abhors vacuum）」ということわざがありますが、ソフトウェア開発では「品質は『突然』を嫌う」が基本原則中の基本原則です。
次回は、「7．未修正のバグが残っていない」を解説します。この条件も、ごく当たり前に見えますが、非常に面倒な要素が隠れています。（次回に続く）
東海大学 大学院 組込み技術研究科 助教授（工学博士）
Copyright © ITmedia, Inc. All Rights Reserved.