メトリクスについて

自分たちのテストや品質に対してどのような立ち位置なのかを判断するにあたって何かいい指標はないものかを思ったのが吉日で、品質メトリクスというものを学ぶことにした

メトリクスとは

メトリクスとは、様々な活動を定量化し、その定量化したデータを管理に使えるように加工した指標のこと。
データを収集し、分析しやすいように計算した値のこと。

その中でも、品質やテストにかかわる品質メトリクスというものがある。

品質メトリクス

レビューやテストを行うときに、どれぐらい実施すればいいのかいいのか判定するモノサシで、以下のものがある。

• レビュー品質メトリクス
• テスト品質メトリクス

レビュー品質メトリクス

設計段階での作成する仕様書などをレビューしたときの、設計書やレビューの精度を評価する数値。

レビュー工数密度

システム規模に対しての文書をチェックするために費やした時間の割合。
システム規模に対してレビュー時間判断をするための数値。

短すぎると見落としが発生する可能性がある、多すぎるとプロセスが回っていないなどの問題がある可能性があるなどの指標となる。

レビュー指摘密度（検出率）

システム規模に対してのレビューで指摘された数の割合。

仕様書やレビュープロセスの精度などを判断する。
システム規模が大きいのに指摘数が少ないと仕様書が完璧なのか見落としが多いのかなど。

レビュー指摘効率

レビュー工数に対してどれだけの指摘数の割合。

仕様書やレビュープロセスの精度などが判断できる
レビュー時間が長いのに指摘がすくないなどがわかる。

テスト品質メトリクス

テスト工程でのシステム（プログラム）の品質を評価する数値。

テスト密度

システムの規模に対してテスト項目（ケース）数の割合。
システムにの規模によるテスト項目数の妥当性などが判断できる。

バグ密度

テストによって検出したバグの数の割合。
システム（プログラム）の品質やリスクなどの指標になる。

考察というか悩みなど

システム規模っというのがでているが、これはどういうふうに計測するんだんろうか？
ページ数とかいうけど、無駄にページ数が多くてレビュー密度がさがったら意味がないと思うし。。。
経験的に大中小とか定性的にシステム規模を出すしかないのだろうか？

レビューした結果、誤字などの指摘などは指摘個数には入れるものなの？
そんなものまで入れると、ものすごく指摘個数があがって本質的なレビュー指摘のメトリクスから外れるんじゃないのかな？

バグ密度が、どうして分母が「テスト項目（ケース）数」なんだろうか？
なんとなく分母は「（修正や追加した）コード行数」じゃないのか？っと思っていたので見ているうちに、なんとなく テスト密度 * バグ密度 でコードに対してのバグの割合となるので縦軸、横軸の表に表しやすいということなんじゃないか？ということで落ち着いた。