この記事の想定読者
・テストの段階で進捗管理やリリースの判断に悩む人
・テストのマネジメントに興味がある人
・テストのマネジメントに興味はないが、テストを測定することには興味がある人
この記事のゴール
・テストの進捗やリリースの判断基準を定量的に把握するためにテストメトリクスという方法があることを知る
・テストメトリクスの使い方を知る
・テストをメトリクスの種類を知る
テストメトリクスとは何か?
テストの"何か"を定量的に表現したもの。
"何か"は後述します。
テストメトリクスがあると何がうれしいか?
テストの管理(モニタリング&コントロール)ができる
- テストメトリクスを通じて、テストの状態を定量的に把握できるようになります。それがなぜうれしいのでしょうか。システム開発では、テストを通して出来上がったプロダクトや残り時間などの現状を把握する必要があります。現状を計画と比較します。そして、その間にギャップがあるならば、それを是正するための打ち手(コントロール)が必要だと分かります。
- そういう点で、テストメトリクスを用いてテストの現状を可視化することは役立ちます。
ステークホルダーにテストの状況を報告できる
- プロジェクトマネージャーやプロダクトオーナー、スポンサーなどに
テストの状況や開発されたプロダクトの品質などを定量的に伝えることができます。
テストの傾向の発見と原因分析ができる
例えば、欠陥をサブシステムごとに分類して集計していたら、
バグが特定のサブシステムに偏って発見されていることに気づくことができる。
では、いかにしてテストメトリクスは状況を可視化するのでしょうか？
テストメトリクスの使い方
- 測定対象を定義する
- 例：テストで発見された欠陥の数
- データの収集と集計の方法を定義する
- 必要あれば、テストメトリクスの報告方法と頻度を決める
- テストメトリクスを見て、計画通りかどうかを検証する
テストメトリクスの種類
分類法はいくつかあります。
2つご紹介します。
メトリクスが何を表現するか、
メトリクスのために何のデータを収集するか、
です。
テストの現場では、何を表現したいかと収集できるデータとの兼ね合いで
メトリクスを選択することになると考えられます。
何を表現するかに基づく分類
プロジェクトメトリクス
テスト終了基準に対する達成度を表現する
例：全体に対して完了したテストケース数の比率
プロダクトメトリクス
プロダクトの属性を表現する
例：欠陥密度
プロセスメトリクス
テストプロセスがどれだけ効率的か、効果的かを表現する
例：コードレビューによって検出できた欠陥の割合
人的メトリクス
要員の生産性を表現する
例：一日あたりのテストケースの実行数
プロジェクトメトリクスはさらに細分化できる
| 表現するもの | メトリクスの例 |
|---|---|
| テスト計画 | 要件定義書内の要件のカバレッジ |
| テスト分析活動(※1) | テスト条件の数(※2) |
| テスト設計活動(※3) | 作成したテストケースによりテスト条件を網羅している割合 |
| テスト実装活動(※4) | ロード済のテストデータの割合 |
| テスト実行活動 | 何件のテストケースがfailしたか |
| テストの進捗 | プロダクトリスクの内、軽減したリスクの数 |
※1
テスト分析活動 = 何をテストするかを定義する活動
※2
テスト条件 = テスト対象。ただしテストケースより上位にあり、抽象的。
例：Xというボタンが動作するというテスト条件、Yという計算結果が正確に出力されるというテスト条件
※3
テスト設計活動 = どうやってテストするか、つまりテストケースを作成する活動
※4
テスト実装活動 = テスト実行のための準備。テストデータ作成、テスト自動化など。
収集するデータの種類に基づく分類
プロダクトリスクに基づくメトリクス
終了基準として使える
例1：テストを通じて対応されたリスク/全リスク
例2：完了していないテスト/全体のテスト
例3：残存するリスク/プロダクトリスク分析で洗い出された全てのリスク
欠陥に基づくメトリクス
例1：修正済みの欠陥数/発見された欠陥数
例2：カテゴリーごとの欠陥の数/全体の欠陥数
例えば、優先度ごとの欠陥の数
例3：欠陥の報告から修正までのリードタイム
例4：デグレを起こした修正の数/全体の修正した数
テスト結果に基づくメトリクス
例1：テスト結果ごとの割合 (例えば、Fail 10%, Pass 90%)
例2：リグレッションテストのステータス
例3：実際のテストに割いた時間/計画上の1日あたりのテストに割く時間
例4：テスト環境を使える時間/計画されたテスト時間
カバレッジに基づくメトリクス
例1：テスト済みの要件/すべての要件
例2：テストされたリスク/すべてのリスク
例3：テストを実行したコードの量/全てのコードの量
メトリクスを使う際の注意点
メトリクスの選定に気を付ける
メトリクス同士のバランスに気を付けてメトリクスを選定すること。
例えば、テストの進捗を表現するために、テストに割いた時間のみをメトリクスとすると
誤解を与えるかもしれない。加えて、修正が必要なテストケース数のメトリクスを追加する方が正確な進捗状況を表現できるだろう。
誰のための報告かを意識する
メトリクスを使ってテスト結果を報告する場合、誰に向けて報告するかを意識して
内容を考えること。報告先の例えば、プロジェクトマネージャーはどんな欠陥が見つかったかに興味がある一方、ビジネスに関する意思決定をする人は欠陥がどんなビジネス上の影響があるかに興味があるだろう。このように、報告先のニーズ次第で適切なメトリクスが異なるかもしれない。
メトリクスの数は程々に
メトリクスが必要以上に多くなりがち。
多すぎてもデータ収集の手間が増えたり見る側は時間がかかる。
データの収集と集計の方法
データの収集は手間が減るように自動化するとよい。
メトリクスの有効性
せっかくメトリクスを用意しても、それが誰かの情報のニーズを満たさないならば役に立たない。
メトリクスの解釈
ステークホルダーの間でメトリクスの解釈が合意できるようにする。
例えば、一日当たりのテストケースの消化数をプロセスメトリクスだと解釈するのが間違いの場合がある。たくさん消化したからといって、効率的にバグを発見できているとは限らないからだ。
参考資料
テスト技術者資格制度 Advanced Level シラバス日本語版 テストマネージャ
2012年のバージョンなので英語版よりも古い。
https://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TM_Version2012.J04.pdf
ISTQB Certified Tester Advanced Level Test Management Syllabus
2023年に大きめの改訂がされた。英語。
https://istqb-main-web-prod.s3.amazonaws.com/media/documents/ISTQB_CTAL-TM_Syllabus_v3.0_zKjKsaN.pdf