1．概要
ソフトウェアテストの品質を測る上で、「どのメトリクスを使うか」で品質の測定方法や監視すべき項目が決まってきます。本件では、
- どのようにして収集すべきメトリクスを決めればいいのか？
- どんなメトリクスがあるのか？
- メトリクスを測定することで何がわかるのか？
を説明します。
2．メトリクスを決定する方法
メトリクスを決定する上で行ってはいけないことは、理由もなくとりあえずIPAや参考書が記載しているメトリクスをそのまま利用することです。なぜなら、理由もなく導入した場合、算出された結果がいいのか悪いのか、後々判断できなくなるからです。
例として以下の図を確認し、質問内容について考えて見てください。
質問：総合テスト後の品質は良いのでしょうか？悪いのでしょうか？
品質が良いのか悪いのか、どちらの意見を持ちましたか？
おそらく以下のような意見が上がると思います。
■品質が良いと思う理由
- バグが工程を進むごとに減っている。
- 「単機能動作」の不具合が総合テストで検出されていない。
- 予定外の不具合である「想定外の事象」が、どの工程でも検出されていない。
■品質が悪いと思う理由
- バグ件数の総和が多い。
- 機能テストで出すべき「設計誤り」が総合テストで検出されている。
- 「複数機能動作」が結合テストで検出しきれておらず、機能テストで増えている。
いかがでしょうか？
品質が良い理由も悪い理由も、両方思いついたのではないでしょうか？
これが理由もなくメトリクスを導入することの弊害です。要は目的のないメトリクスを集めても、結論から品質が良い悪いを判断することは非常に難しいということです。
（結果をいろいろと深読みすることができるので、良い悪い両方の意見が集まることになる）
そのため、どのメトリクスを導入するかは「GQM」という考えに基づいて決定すべてきだと思っています。
GQMは、
- Goal：目的、目標、達成したいこと
- Quesion：質問、目標のために何を、どこで、どのように…といった質問を投げかける
- Metrics：質問を確認するために必要なメトリクスを定義する（複数定義されることもある）
を用いてメトリクスを定義する方法方で、要は「目的」に基づいて必要なメトリクスを定義しよう、ということです。
例えば以下のように、
- Goal：検出される不具合の数を減らしたい
- Question： どのくらい不具合が検出されているのか？何が原因で不具合が起きているのか？
- Metrics：不具合数、不具合の影響度、不具合の原因
とすることで、なんのためにメトリクスを収集するのか、理由付けを行うことができます。また、目的を定義しているため、取集したメトリクスの使い方も理解しやすくなっています。
3．テストの品質管理で使われるメトリクス一覧
Goal、Quesionを決定したが、どのようなMetricsを定義すればいいかわからない場合、以下の表を参考にしてみてください。
※間違いもあるのでちょこちょこ修正中…
| メトリクス名 | 計算方法 | 利用方法 |
|---|---|---|
| テストケース数 | - | テストの進捗管理、テストの妥当性確認に利用 |
| テストケースのOK数 | - | 期待結果通りとなったテストケースの数。テストの進捗管理に利用。 |
| テストケースのNG数 | - | 期待結果と異なるテストケースの数。テストの進捗管理に利用 |
| テストケースのPN数 | - | テスト実施できないテストケースの数。テストの進捗管理に利用 |
| テストケースの除外数 | - | 削除したテストケースの数（機能がリリースされなくなった、などの理由）。テストの進捗管理に利用 |
| テストケース密度 | テストケース数/LOC\nテストケース数/FP | テストケースの量が十分足りているか測るのに利用 |
| テストケースの分類 | - | 機能名を書いたり、入力チェック、エラー確認などテストの方法を書いたりする。何をテストしたのか全体を表すのに利用 |
| ステートメントカバレッジ（C0） | 実行した命令/すべての命令数 | ホワイトボックステストの充足度を測るのに利用 |
| ブランチカバレッジ（C1） | 実行した判定条件/すべての判定条件 | ホワイトボックステストの充足度を測るのに利用 |
| 単純条件カバレッジ（C2） | 実行した条件/すべての条件 | ホワイトボックステストの充足度を測るのに利用 |
| 欠陥数 | - | 品質が良いのか悪いのか判断するのに利用 |
| 欠陥密度 | 欠陥数/LOC\n欠陥数/テストケース数 | 欠陥が多いのか少ないのか測るのに利用 |
| 欠陥の重要度 | - | 高中低の3段階か、1～5などの数値で表現。ユーザに大きな損害を与える、もしくは開発中に問題が起きそうか判断するのに利用 |
| 欠陥の影響度 | - | 高中低の3段階か、1～5などの数値で表現。テストの進捗に影響を与える、もしくはそのほかの機能に問題が起きそうか判断するのに利用 |
| 欠陥の優先度 | - | 高中低の3段階か、1～5などの数値で表現。不具合をいつまでに修正してほしいか判断するのに利用 |
| 欠陥の発生頻度（再現率） | 欠陥が発生した数/テストの実施数 | 不具合がどのくらい再現するるのか再現確認に利用。組み込み系のハードウェアが関連するものに良く利用される |
| 欠陥の分類 | - | レイアウト、文言誤り、データ更新、エラーチェックなど、欠陥の属性を記載する。欠陥の偏りを分析するために利用 |
| 欠陥の原因 | - | 分類項目を作成してもいいが、どの分類にすべきか迷うことが多いので、一旦文章で記載する |
| 作りこみ工程 | - | 要件定義、基本設計、詳細設計など、どこで不具合が発生したか偏りを確認するために利用 |
| テスト工数 | - | 時間or人日or人月で表す。工数の妥当性確認や人の評価に利用 |
| レビュー指摘件数 | - | レビューの品質を測るために利用 |
| レビュー指摘総数 | - | レビューの指摘数が妥当か測るために利用 |
| 予定レビュー指摘数 | - | レビューで指摘するべき予定数を記載。レビューの指摘が実績と比べ妥当であったか測るために利用 |
| お客様レビュー指摘数 | - | 自社開発メンバーではなく、お客様（エンドユーザ）の指摘数。お客様の求めたものができていたのか測るために利用 |
| レビュー工数 | - | 時間で表す。レビュー工数の妥当性確認や人の評価に利用 |
| レビュー工数密度 | レビュー工数 / レビュー対象規模 | 対象システムの規模に対して、レビュー時間が妥当であったか測るために利用 |
| レビュー指摘効率 | レビュー指摘件数 / レビュー工数 | かけた時間に対してレビュー数が妥当であったか測るために利用 |
| レビュー指摘密度 | レビュー指摘数 / レビュー対象規模 | 対象システムの規模に対して、指摘数が妥当であったか測るために利用 |
| レビュー指摘重要度 | - | 高、中、低など、レビューの指摘がどれだけ重要であったか測るために利用。大きさは市場に流出した場合のユーザへの影響度や、開発者の主観によって決定する |
| 開発機能数 | - | 開発する機能の数。開発規模の大きさを測るのに利用 |
| LOC | - | ソースコードの行数。開発規模の大きさを測るのに利用 |
| FP | ※1 資料参照 | 機能の大きさを測るのに利用 |
| 画面数 | - | 画面の大きさを測るのに利用 |
| 機能数 | - | 機能の大きさを測るのに利用 |
| バッチ数 | - | バッチの大きさを測るのに利用 |
| ページ数 | - | ドキュメントのページ数。ドキュメントの大きさを測るのに利用 |
| ドキュメント密度 | ドキュメント数 / LOC（画面数や機能数でもいい） | 規模に対して作成したドキュメントの量が妥当か測るために利用 |
参考資料
※1 FP法：https://ssaits.jp/promapedia/method/function_points.html