テスト計画・テスト管理のメトリクス（その２）：テスト結果の管理
テストの結果は実施状況と成果物の２種類のメトリクスで管理する
ソフトのテスト計画書ではテスト結果の管理の方法についても書いておきます。ソフトとのテスト結果の良し悪しは目に見えないので管理がやり難いですが、テスト結果の管理はテスト実施状況の管理とテスト成果物の管理に２つに分けてメトリクスを決めて管理するのが判り易いです。またこの記事では、テスト結果のトラッキングについても後半で紹介します。
テスト結果の管理はテストの実施状況の管理とテスト成果物の管理の２種類に分かれます。このうちテストの実施状況についての管理は日程の進捗管理にも使えるのですが、結果の管理のほうが主体なのでこちらの分類で説明します。テストの成果物についての管理はテストで検出した不具合についての管理です。それでは、順番に具体的に見ていきましょう。
テストの実施状況の管理に使うメトリクス
テストの作業が始まると、テスト項目やテスト手順書やテスト要領書に書かれた内容に従って、複数名のテスト作業員が一斉に実際のテストを進めていきます。うまく実施できるテスト項目もあれば、実施のできないテスト項目もあります。
実施の出来ないテスト項目とは、例えば既存のバグのためにテスト手順が進められないとか、今回のテスト対象のソフトにはまだ実装されていない、とかで、テストの現場でのあるあるですね。そのため、テストの実施状況もしっかりと管理しておかないと、計画通りにテストが進まない事が多いです。では、テストの実施状況に使えるメトリクスを見ていきましょう。
（１）テストのブロック率
機能が未実装とか他のバグのためにテスト手順が進められないとか、いろいろな理由でテストそのものが実施できない場合があります。このテストが実施できない状態をテストがブロックされていると表現します。テスト項目毎の状態をどう定義するかにもよりますが、簡単な定義だと以下の４つの状態を使います。
- テスト未実施（テストを実施する日程がまだ先なのでテスト作業をしていない）
- テスト完了（テストの結果ＯＫ判定となった）
- 再テスト待ち（テストの結果ＮＧ判定となったので修正版ソフトで再テスト待ち）
- ブロック（テストを実施できなかったのでブロック条件の解除待ち）
２と３はテストが実施できた状態で、４はテストを実施する予定の日が来たのにテストが出来なかった状態です。この 4のブロックされているテスト項目の件数を、その日までに実施される予定だったテスト項目の件数で割り算して、テストのブロック率を計算します。式にすると以下ですね。
テストブロック率（％）＝現時点でのブロック状態のテスト項目数 X 100 /
（ 現時点までにテスト完了したテスト項目数 ＋
現時点までの再テスト待ちになっているテスト項目数 ＋
現時点でのブロック状態のテスト項目数）
テストの計画どおりにテストの実施が進めばテストのブロック率はゼロなのでこのメトリクスの目標値はゼロです。しかし実際には様々な理由でテストのブロック状態が起きます。テストのブロック率が低ければ、個々のブロック条件の解除を待っていれば良いのですがテストのブロック率が15% を超えるようなら、何等かの対策を考えるのが良いでしょう。
（２）再テストの実施率
テストを実施して結果がＮＧだった場合には、普通はそのＮＧ項目の対策を行って再テストをします。再テストが必要になる理由も、ソフトのバグだったりテスト環境の不備だったりといろいろな原因がありますが、再テストを実施するとい事実には変わりません。
そして、再テストを実施するという事は、１つのテスト項目について最初の計画の２倍のコスト（人件費、機材時間など）を掛ける事になるので、テスト作業の効率の低下が起きます。ですので、再テストの実施率を監視する事で、テスト作業の効率の低下状況を判断する事ができます。再テストの実施率は、式にすると以下ですね。
再テストの実施率（％）＝現時点までに再テストを実施したテスト項目数 X 100 /
（ 現時点までにテスト完了したテスト項目数 ＋
現時点までの再テスト待ちになっているテスト項目数 ＋
現時点でのブロック状態のテスト項目数）
なお、同じテスト項目について再テストが３回、４回と繰り返されるような場合には、式の分子を再テストののべの実施回数とっしたほうが良いかも知れません。このあたりは、各々の組織での再テストの状況で判断すれば良いと思います。
テストの成果物の管理に使うメトリクス
テストの成果物（アウトプット）はテスト結果ですが、その成果物の中でもテストＮＧとなった不具合が一番重要なので、この不具合についてはしかっかりと管理する必要があります。では、テストで発見した不具合を管理するメトリクスを見ていきましょう。
（１）不具合の検出件数
テストの成果物のメトリクスとして一番良く使うのが不具合の検出件数です。日々何件の不具合を検出しているのかを集計しグラフにプロットする事で、テストが計画どおりの効果を挙げているかを、定性的にですが判断する事ができます。
不具合なので、その原因はソフトのバグだったり、テストデータの間違いだったり、テスト手順の間違いだったりと、色々です。ですので、不具合の検出率は検査対象のソフトの品質状況ではなく、テストそのもの品質状況（質の良いテストができているか）の管理に使うというと所に少し注意しましょう。ソフトの品質状況はこの後に出てくるバグについてのメトリクスで管理します。
（２）バグの検出件数
ソフトのテストの目的の１つが潜在バグの検出とデバッグによる品質改善なので、バグの検出数は大切な管理項目です。テストの経験を積んでくると、以前の良くにたソフトのテストの経験を元にして、今回のテストチームの力量と設計チームの人員や開発の難しさ等を加味して、どの程度のバグが検出されるか、凡そのバグ件数が推測できるようになってきます。その推測したバグの件数に対して、現在検出されバグの件数が多いか少ないかは、テスト対象のソフトの品質とテストそのものの品質の両方を推し量るメトリクスになります。
なお、ソフト開発の規模が異なる時には開発・修正したソースコードの KLOC 数で字割り算して正規化したバグ密度をメトリクスとして使ったほうが良い場合もあります。
（３）バグの検出率（バグ検出曲線の寝具合）
テストをいつ迄続けるのか、言い方を変えればもうテストを終了しても良いのかというテスト終了の判断に使うメトリクスとしてバグの検出率があります。バグ検出率は、発見したバグの件数 / テスト項目数やテスト工数 で計算します。このバグ検出率が判断値よりも小さくなったら、十分な量の潜在バグを洗いだせたので残っている未検出の潜在バグは少ないだろうと考えてテストを終了する、という判断をします。
例えば、バグ検出率が 0.2件/10人日 を下回ったとすると、50人日のテストをして１件のバグが見つかるという事なので、テストを終わってもいいよねというような判断の仕方です。もちろん、どんな判断値にするのかは、そのソフトに求められる品質のレベルによって変わってきますが、このようなテスト終了の判断の仕方も必要です。
なお、テストの終了判断によく使われる、ゴンベルツ曲線とかバグ曲線とか信頼度成長曲線と呼ばれる曲線は、横軸をテスト工数やテスト量とし縦軸を累積のバグ検出数としてプロットして作成します。この曲線の傾きは、実はバグ検出率に相当します。ゴンベルツ曲線やバグ曲線は、テストを終了しても良いかどうかの判断を曲線が十分に寝ているかどうかで判断しますが、これはバグ検出率が十分に小さくなっている事と同じ意味です。
（４）バグ比率（不具合の中に占めるバグの割合）
ソフトのテストの目的の半分は、はソフトに潜在するバグを見つけ出してデバッグサイクルを回しソフトの品質を改善する事です。ですので、検出した不具合のうち何％がソフトのバグだったのというバグ比率は、テスト作業の品質を管理するメトリクスになります。式で表すと以下ですね。
バグ比率（％）＝ これまでに検出されたバグの累計件数 X 100 /
これまでに検出された不具合の累計件数
テスト手順の間違いやテスト用データの間違い等、ソフトのバグ起因以外の原因による不具合が多数検出されるようならば、テストの品質に何か問題がると考えて早めに対策を取るのが良いでしょう。
（６）バグの滞留状況
発見されたバグはソフト設計者や実装者の手に渡されてバグ修正が行われます。そのバグ修正を終えたソフトで再度テストを実施して、テスト結果がＯＫとなれば検出されたバグに対する対応が終了します。
検出されたバグの件数が少ない時には、設計・実装の担当者も相手にするバグの数が少ないので、見つかったバグはどんどん修正されていきます。ところが、設計・実装担当者のデバッグ速度を上回る速度で新たなバグが検出されると、対応が終わったいないバグの件数がどんどん溜まっていきます。所謂、デスマーチの始まりですね。
テストで検出されたバグのうち、対応が終了していない＝処理が滞留しているバグの件数は、ソフト開発の最終段階のデバッグ作業が順調かどうかを判断する大切なメトリクスです。設計・実装チームのデバッグ能力が 10バグ/日 だとすると滞留バグが100件あればデバッグ完了まで10日掛かります。それまでにリリース日が来るようなら、設計・実装チームの人員を増やしてデバッグ能力を改善しないと、リリース日に間に合わなくなります。その様な事にならないように、バグの滞留状況はよく注意して管理する事が大切です。
テスト管理結果のトラッキングはテスト管理で最重要
テスト成果物についてのメトリクスの中のバグの滞留状況の紹介でも書きましたが、テストで見つけたバグは、デバッグして治っている事をテストで再確認して対応が終わります。この間、バグの状態は①バグ検出 ②バグの再現 ③バグの原因調査 ④バグの修正 ⑤修正効果の確認 ⑥二次不具合の確認 ⑦マスターツリーへの修正反映 ⑧修正を織り込んだデバッグ版ソフトでの再テスト とデバッグサイクルの各段階を進んでいきます。
テストで検出された各々のバグが、上記のデバッグサイクルのどの段階まで進んでいて、今は誰が次の作業をしているのか、バグの対応の状況を追いかける事をバグのトラッキングやトレースと呼びます。バグの件数が少なくて設計・実装チームとテストチームが同じ事務所に集まっているなら、事務所のホワイトボードに書いたバグ一覧表でトラッキングをする事もできます。一方でバグ件数が多く、設計・実装チームとテストチームが離れた拠点にいる場合等は、何等かのバグトラッキングシステムを使ってバグトラッキングを行います。
いずれにしても、バグのトレースあるいやバグのトラッキングを、どんなツールを使って、どんな頻度で、誰が行うのかは、テスト管理の最重要な項目なのでテストの設計時にしっかりと決めておきましょう。
テスト管理の間隔と分担もテスト計画で決めて置く
テストの管理をどの程度の頻度で行うのか、という管理の間隔もテスト管理の計画段階でしっかりと決めて置く必要があります。工場の製造ラインのように、毎日同じ作業を続けるのであれば日日の監視をしてで小さな計画からのブレを見逃さずに細かく管理していく事が重要です。しかしソフトのテスト作業は、作業手順書があるとは言っても、日々異なる作業の連続なのでどうしても計画からのブレは起きます。
なので、ソフトのテスト管理の場合は３営業日とか５営業日毎に状況を監視して遅れが２回か３回以上継続していて計画からのズレが回復する様子が見られない場合に対策を行う、という程度の管理の間隔でも良い場合が多いです。
なお、このようなテストの管理を行うには、実体を監視するために実績の収集と計画からのズレの分析を行う分析担当者と、分析した結果を元に問題の有無を判断し問題があれば計画からのズレを修正する対策を指示する対策の指示者が必要です。このテスト管理に必要となる分析担当者と対策指示者もまた、テスト計画の段階で明確に決めておく事が大切です。
テスト管理の次ぎはテスト環境です
この記事と前の記事ではテスト計画書に書くテスト管理について紹介してきましたが、イメージはつかめましたでしょうか。テスト管理が掛けたら、次はテスト環境について続く記事で紹介していきましょう。