テスト報告書・発見したバグは分布が判るように分析する
ソフトのテスト報告書にはテスト結果として検出したバグの分布を書く
ソフトのテスト報告書にはテスト結果とテスト評価を書きます、簡単に言うとテストで検出したバグの状況がテスト結果で、テスト作業の良し悪しがテスト評価です。バグの状況を書く時にはうまく分析して書いておかないと、リリース判定の時に品質の良し悪しの判断に使いずらくなってしまいます。
どんな機能でバグが多かったのか、どんなテストでバグを沢山見つけたのか、重度のバグはどの程度あったのか、などリリース判定の時にソフトの品質を判断するための情報を提供できるように、見つけたバグの分析結果をテスト報告書に書いておきます。どのような分析の仕方があるのか、グータラ親父が見てきた例を元に少し具体例を紹介してみましょう。
ソフトの機能やテストの種類ごとにバグの件数や密度を分析する
まずは、どこでバグが大量に検出されたのかという視点での分析です。分析する時には、検出されたバグの絶対数も大事ですが、それだけだと新規開発や修正を多くした箇所のバグ件数が大きく見えるのは当然なので、新規・修正したソースコードの KLOC 数で正規化したバグ密度（XX件/KLOC）や、テストの項目数で正規化したバグ密度（XX件/テスト数）を使って分析するほうが、バグの偏在状況を正しく表せる事が多いですので、絶対数とバグ密度を併記するのが良いですね。
どこでバグが検出されたかの分析の仕方には、ソフトの機能ごとの分析とテストの種類ごとの分析の２つがありますので順に紹介していきましょう。
（１）ソフトの機能ごとのバグの検出状況
バグの分析で一番簡単なのは、今回のテストで検収されたバグをソフトのどの機能に関するバグなのかで分類して機能ごとにバグの件数やバグ密度を計算するという分析方法です。機能Aで 5件 (0.2件/KLOC) 機能B で12件（0.5件/KLOC) のように数字を並べていく方法ですね。こうする事でどの機能で多くのバグが検出されたか、どの機能でのバグ密度が高いのかが見えてきます。
ソフトの構造が複雑だったとか処理タイミングが難しかったとか、ソフトの設計・実装上で難しい点がある機能でバグ密度が高いのは誰でも納得のいく結果ですので安心です。でももしも、比較的簡単な機能でバグ密度が高いようなら、何が原因だったのか今一度確認しておくのが良いです。設計・実装担当者の経験が浅かったのでケアレスミスによるバグが多数見つかっているようなら、その担当者の開発したコードに付いて再度コードレビューをしておく、等の補助的な対策が要るかもしれません。
（２）テストの種類ごとのバグの検出状況
２つ目の分析の方法はテストの種類ごとの分析です。テストは別の記事にも書きましたが、色々な目的に沿ってさまざまな名前のテストに分類して計画・実施されています。このテスト名ごとにバグの検出数を分類してみると、ソフトの品質の面からみてどんな点が弱かったのか傾向が見えてきます。なお、この分類の場合にはテスト項目数で正規化したバグ密度（XX件/テスト数）を使うのが良いです。
例えば、正常系のテストの多くのバグが検出されているとすると、それは今回のテストの前に実施されているはず単体テストで見つけるべきバグが今回のテストまで漏れ出してきているとみる事ができます。単体テストのやり方が悪かったのか単体テストをやってる時間が足りなかったのか、何か開発プロセスに問題があった可能性が在るのかも知れません。
大規模テストや高負荷テストなど、安定性を見るテストで多くのバグが見つかっているとすると、今回の開発内容がシステムの安定性に影響を与える箇所だったのかも知れません。あまりにもバグの数が多いようなら、まだ見つかっていないバグが潜在しているかも知れないので、リリースは少し先に延ばして、もっと安定性についてのテストをしたほうが良いかも知れません。
安定性等についての品質の懸念がある時には、可能ならば同じ製品の１つ前のバージョンのソフトでのテストの種類ごとのバグのを併記した、バグ密度の差異がどの程度あるかも見ると、今回のソフト開発に固有の問題なのかを判断する材料にもなります。
バグの起き易さや重要性などに注目してバグ密度を分析する
どこでバグが検出されたかの分析の次ぎは、どんなバグが検出されたのかという視点からの分析です。この分析では検出したバグをいくつかに分類して、全体のバグ件数に対して何％がその分類のバグだったのか、という分析の仕方をします。分類の仕方には色々ありますが、代用的なものはバグの起き易さやバグの重要性ですので、少し具体的に見てみましょう。
（１）バグの起き易さに従った分類
バグは何等かの発生条件が揃った時に不具合の状態を引き起こします。条件が揃い易いバグは起き易いですし条件が複雑なバグは起こり難いので、バグの起き易さから次のような分類ができます。
- 単純条件バグ：１つの条件が揃うと必ず不具合を起こすバグ
- 複合条件バグ：２つ以上の条件が同時に揃うと必ず不具合を起こすバグ
- 確率発生バグ：発生条件が揃った上で何回かに１回の確立で不具合を起こすバグ
確率発生バグは発生条件の中になんらかのタイミング依存性がある場合です。例えば、ある特定の値が入力されるという通常の条件と、外部との通信の終了処理が起動されるというタイミングに依存する条件が重なった時に不具合を起こすバグです。この場合、外部との通信処理が起動されるタイミングの起きる確率が100回に1回だとすると、特定の値が入力される処理が100回実施されるとその内の１回で不具合が起きる事になります。
テストによるバグの検出の難しさというか検出に掛かるコスト（手間暇や機材や時間）でいうと、c > b > a の順番です。という事は、テストで見つけたバグのうち、b や c のバグの比率が高いという事は、それだけ手のかかるテストを実施できたという事で、テストの質が良かったと判断する事ができます。逆に a のバグばかりだと、さすがにテストの品質を見直した方が良さそうです。
（２）バグの重要度による分類
バグはそれによって引き起こされる不具合内容の重要度によって分類する事も大切です。あまり使わないような表示の間違いを起こすバグも、装置の機能に大きな影響を与えるバグも同じバグですが、後者のほうがより重要度が大きいバグです。 そのような観点でバグを分類する一例は、以下のようになります。
軽微なバグ：表示の違いなど装置の基本機能に影響しない不具合 (Minor Bug)
通常のバグ：基本機能一部に軽微な影響がでるか補助機能が使えなくなる不具合 （Major Bug)
重度のバグ：装置の基本機能の一部が使えなくなる不具合 (Critical Bug)
緊急のバグ：装置の多くの機能が使えなくなる不具合 （Show Stopper)
ゲームソフトで例えると、軽微なバグはキャラのデザイン表示が一部変、というようなバグです。通常のバグは特定のコマンドの発動条件が一部間違ってる、という感じでしょうか。重度のバグは特定のコマンドが発動しないとか効果が違う、ですね。緊急バグはログインできないとかゲームの場面が進まない、でしょうか。
重度のバグや緊急のバグは、テストの終了時期の間際に見つかるとそれを修正している時間の余裕がとれずソフトのリリース計画が崩れてしまいます。なので、重度のバグや緊急のバグの比率が高いようではソフト開発プロジェクトとしてのリスクが高いので、いろいろな面で注意や改善が必要です。たぶん、単体テストや設計レビューなどの上流工程での品質確保の活動にもっと人手と時間を投入するような開発計画が必要だったのだろうと思います。
見つけられなかったバグについての考察も重要です
テスト報告書にはテストで見つけたバグについての分析は必須ですが、ソフトの品質の判断のための情報としてはまだ見つけていないバグについての推測もとても重要です。まだ見つけていないバグについて何が書けるのか、次の記事で紹介します。