テスト計画・テスト管理のメトリクス（その１）：日程と成果物の進捗管理
テスト管理では管理に使うメトリクスを最初に決める
ソフトのテスト計画書にはテストの管理にどんなメトリクスを使うのか、メトリクスを監視する間隔はどの程度にするの、メトリクスで問題が見つかった時の対応はどうするのか、についても具体的に書いておくのが良いです。
テスト管理のメトリクスとして使い易いのは、日程の進捗管理と成果物の進捗管理です。この記事では、グータラ親父が見てきたテスト計画書を例に、どんなメトリクスがあるのかの概要を紹介し、その後に主にテストの進捗管理に使うメトリクスについて具体的な内容を見ていきます。
テスト目標をメトリクスに使うならテスト期間毎に細分化する
テスト管理に使うメトリクスとして最初に思い浮かべるのはテスト目標です。納期、コスト、プロダクト品質、プロセス品質、作業品質、管理品質 など幾つかの観点に沿って具体的・定量的なテスト目標が作られているはずなのでこれは管理のメトリクスに使えます。しかしテスト目標はテストが終わった時に最終的に到達しているゴールを示す事が多く、それでは管理に使いにくいのでテスト期間毎に細分化する必要があります。
例えばテスト目標としてバグ検出率を 0.1バグ/テスト項目 と決めたとします。この目標の意味は、全てのテストが終わった時に 総バグ検出件数/総テスト項目数 で計算される値の目標を 0.1 とする、という事です。この目標値をそのままテスト管理で使おうとする、目標値 0.1バグ/テスト項目の値に対して今の時点でのバグ検出率の実績値を計算して、実績値が目標値を満たしているかどうかを監視し、差異があればその対策を進める事になります。
ところが実際には、テスト実施の最初の 30% 程度の期間では単純バグがよく見つかるのでバグ検出率は 0.2バグ/テスト項目 程度になり、テストの最後の30%程度の期間ではとても複雑なバグしか見つからないので、バグ検出率は 0.05バグ/テスト項目まで低下する、というのが良くあるパターンです。テスト期間の全てについて、最終目標の 0.1バグ/テスト項目と実績値とを比較していては、あまり良い管理にはなりません。
ではどうするかというと、テスト期間を幾つかに分割して、例えば最初の期間は 0.2 バグ/テスト項目、最後の期間は 0.05バグ/テスト項目 というように、期間毎にバグ検出率の目標を細分化して設定する事で、より正しい管理ができるようにします。このように、テスト目標で決めたメトリクスをテスト管理に使う場合のは、必要に応じてテスト期間毎に細分化した目標をテスト計画書に書いておきましょう。
テスト目標以外のメトリクスを管理に使っても良い
テスト管理に使うメトリクスは何もテスト目標だけではありません。テスト目標であっても実績の収集に大きな手間がかかるなら、テスト管理には使いにくのでテスト管理のメトリクスから外す事もあります。逆にテスト目標には入れていないけど、定期的な実績の把握が必要なメトリクスがあるのなら、それはテスト管理にメトリクスに使うのが良いでしょう。ですので、テスト管理の第一歩は、どんな項目を管理したいのかという管理したい項目を決めて、その管理に適したメトリクスを選ぶ事です。 では、テスト管理の項目やメトリクスにどんなものがあるのかもう少し具体的に見ていきましょう。
進捗管理は日程の進捗管理と成果物の進捗管理の２つで考える
テスト工程の進捗管理（工程管理という呼び名もありますがこの記事では進捗管理という言葉を使います）では、別の記事ソフトの開発やテストの進捗管理を定量的に行う具体例２つでも紹介しているように日程と成果物の２つの観点で進捗管理を行うのが良いです。どちらも、収集した実績値を元に目的との対比がし易いメトリクス（評価値）を計算する事で、管理に使い易くなります。では、どんなメトリクスがあるのか少し具体例を紹介してきましょう。
テスト日程の進捗管理のメトリクス
テスト日程の進捗管理で難しいのは、計画した日程からどの程度の遅れが出たら対策を行うのかという管理を起動する判断の基準です。管理の起動判断をできるだけ簡単にできるように、日程の進捗管理を定量化でいるメトリクスの採用が重要になってきます。
（１）マイルストーン完了率
テストの日程計画ではブレークダウンした詳細作業毎に何月何日から開始して何月何日に終了するという日計画ができあがります。この各々の詳細作業の終了日をマイルトーンと見立てたマイルストーンの完了率を進捗管理のメトリクスに使う事ができます。
完了率＝（監視日までに実際終了したマイルストーンの件数 *100）/ 監視日までに終了する予定だったマイルストンの件数 です。全てのマイルストーンが計画通りに終了していれば完了率は100%ですが、幾つかのマイルストーンが予定日を超えていると、完了率は100%にはなりません。この完了率がある程度以下になったら、工程遅延が大きくなってきている事を示します。完了率が85% を下回ると、そろそろ日程計画の見直しが必要と考えても良いと思います。
（２）工数を加味したマイルストーン達成率
マイルストーンの完了率は使い易いメトリクスですが、ブレークダウンした詳細作業の粒度がばらばらだと、実際の進捗をうまく表現できなくなります。例えば詳細作業Ａは工数が５人日で詳細作業Ｂは工数が20人日だとすると、工程遅れによる影響は詳細作業Ｂの方が大きいのですが、マイルストーン完了率ではこの事は考慮されていません。
このように、詳細作業ごとに必要な工数の粒度にバラツキが有る場合には、そのバラツキを加味するための係数を使って補正するという手段があります。
補正した完了率 ＝ （補正係数＊監視日までに実際終了したマイルストーンの件数 *100）/ 監視日までに終了する予定だったマイルストンの件数 と計算式に補正係数を入れてあげます。上記の例だと詳細工程Ａは補正係数＝１、詳細工程Ｂ＝補正係数４ として計算する事で、詳細工程ごとの工数の粒度を補正する事ができます。
（３）工数消化率
日程よりも作業工数に重点を置いて進捗管理を行う事もできます。テストの日程計画ではブレークダウンした詳細作業毎に何月何日までに終わるのかという終了日程と共に何人日の工数が必要なのかを計画します。この各々の詳細作業ごとの工数がどれだけ終了しているかを元に工数の消化率を計算して進捗管理のメトリクスに使うという方法です。
工数消化率＝（監視日までに終了した詳細作業の合計工数 *100）/ 監視日までに終了する予定だった詳細作業の合計工数 です。計画していた作業工数の投入に遅れがあるという事は、何等かの作業の遅れが起きているという事なので、工数消化率を監視する事で日程の管理ができます。工数の消化率は厳密には日程の進捗管理で無いのですが、成果物の進捗管理ではないのでこの記事では日程の進捗管理に分類しています。
テスト成果物の進捗管理のメトリクス
テスト成果物の進捗管理は成果物の出来高を数えれば良いので割と簡単です。テスト設計書のページ数やレビューの実施回数など、テストの成果物の出来高を計画の時点で推定して決めてあれば、その計画に対する実績を確認すれば、管理のメトリクスに使えます。では、何点か具体例を見ていきましょう。
（１）テスト設計書やテスト手順書の完成ページ数やテスト項目数
テスト設計書やテスト手順書はテストの種類などで分割して何種類か作成すると思います。このテスト設計書や手順書のページ数を進捗管理のメトリクスに使います。それぞれのテスト設計書や手順書は、テストの規模や過去からの経験に照らし合わせて、何ページ程度になるか計画段階でページ数を計画（推定）しておきます。この計画したページ数に対して、実際にレビューを終えて作成が完了したテスト設計書や手順書のページ数を実績値とすると、テスト設計の進捗を成果物の量で管理する事ができす。
テスト設計書や手順書のページ数以外にも、テスト設計したテスト項目数も成果物のメトリクスとして良く使います。ただし、テスト項目数を管理のメトリクスに使う時には、項目数の粒度をできるだけ均一にする工夫が必要になります。１つのテスト項目で１つの内容を確認するテストと、１つのテストで５つの内容を確認するテストとでは粒度が５倍違ってきます。テストの作業効率の面からは、１つのテストで５つの確認をするほうが良いので、テスト管理のメトリクスとして使うときに粒度を調整する仕組みを入れておくのが良いでしょう。
（２）テスト設計のレビューの実施回数や指摘件数
テスト設計の直接的な成果物はテスト設計書や手順書やテスト項目ですが、間接的な成果物としてはテスト設計のレビュー回数があります。このレビュー回数も、テストの種類やその規模に応じて、何回程度行うのかテスト設計の段階でレビューの計画回数を決めておきます。あとは、実際に実施したテスト設計のレビュー回数を実績値として集計すれば、テスト設計のレビュー回数を使った進捗管理ができます。
（おまけ）不具合の発見数やレビューの指摘件数はメトリクスとして使い難い
テストの成果物として一番重要なのは、テストで検出した不具合です。この不具合の検出件数をテストの成果物の進捗を管理するためのメトリクスとして使えればいいのですが、残念ながらちょっと難しい面があります。（テスト結果の良し悪しを判断するメトリクスとしては使えますが、進捗管理のメトリクスには使い難い、という意味です）
不具合の検出数は、テスト対象のソフトの出来具合（品質の良し悪し）とテスト設計の出来具合（良いテストかどうか）の２つに大きく影響されます。テスト対象のソフトの品質が悪ければ多くの不具合が検出されますが、テスト設計の出来具合が悪ければ検出される不具合は少なくなります。そのため、何件程度の不具合が検出できるのかをテスト計画の時点で精度よく推定するのは難しいです。
同じような理由から、レビューでの指摘件数も進捗管理のメトリクスには使い難いです。レビューの指摘件数はテスト設計の出来具合とレビューをする人の経験や力量によって大きく変わってしまいます。そのために、レビューで何件の指摘が出るのかをテスト計画の時点で精度よく推定するのが難しいので、管理のメトリクスに使い難いです。
テスト進捗の管理の次ぎはテスト結果の管理です
この記事では、テストの進捗管理に使うメトリクスについて紹介してきました。テスト管理では進捗管理とともにテスト結果の管理も大切です。次の記事ではテスト結果の管理に使うメトリクスについて紹介します。