ソフトウェアテストの品質を測るためのメトリクス 

#1．概要
ソフトウェアテストの品質を測る上で、「どのメトリクスを使うか」で品質の測定方法や監視すべき項目が決まってきます。本件では、

- どのようにして収集すべきメトリクスを決めればいいのか？
- どんなメトリクスがあるのか？
- メトリクスを測定することで何がわかるのか？

を説明します。

#2．メトリクスを決定する方法
メトリクスを決定する上で行ってはいけないことは、**理由もなくとりあえずIPAや参考書が記載しているメトリクスをそのまま利用する**ことです。なぜなら、理由もなく導入した場合、**算出された結果がいいのか悪いのか、後々判断できなくなるから**です。

例として以下の図を確認し、質問内容について考えて見てください。
質問：総合テスト後の品質は良いのでしょうか？悪いのでしょうか？

<img width="600" alt ="image.png" src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/547663/412f69c0-d667-7db0-789a-387c9514892d.png>


品質が良いのか悪いのか、どちらの意見を持ちましたか？
おそらく以下のような意見が上がると思います。

■品質が良いと思う理由

- バグが工程を進むごとに減っている。
- 「単機能動作」の不具合が総合テストで検出されていない。
- 予定外の不具合である「想定外の事象」が、どの工程でも検出されていない。

■品質が悪いと思う理由

- バグ件数の総和が多い。
- 機能テストで出すべき「設計誤り」が総合テストで検出されている。
- 「複数機能動作」が結合テストで検出しきれておらず、機能テストで増えている。

いかがでしょうか？
品質が良い理由も悪い理由も、両方思いついたのではないでしょうか？
これが理由もなくメトリクスを導入することの弊害です。要は**目的のないメトリクスを集めても、結論から品質が良い悪いを判断することは非常に難しい**ということです。
（結果をいろいろと深読みすることができるので、良い悪い両方の意見が集まることになる）
そのため、どのメトリクスを導入するかは「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