JSTQB ALTM メトリクスの自動収集
JSTWB ALTMシラバスの「2.6 テストメトリクスの定義および使用」からの学びを現場にどう適用するかの思考を記録する。
メトリクス収集・評価は必須と理解
マネジメントの世界には、「測定できるものは達成できる」という決まり文句がある。さらに、「測定されないものは実行されない」というのもあり、測定されないものが無視されやすいことを示している。
テストにおいて、メトリクスを適切かつ十分に収集・分析・評価をできたためしがない。それもそのはず、計画時点でそれを検討したことがないため。
これから効果的な測定により、高品質を確保できるようにしたい。
メトリクスの分類
テストメトリクスは、次の1 つ以上のカテゴリに分類される。
・プロジェクトメトリクス
・プロダクトメトリクス
・プロセスメトリクス
・人的メトリクス
上記のようなカテゴリがあることを理解すると、「何を収集すればよいのか」を考えやすくなる。ちなみに、
Advanced Level では、ほとんどの場合、テストの進捗を測定するメトリクス、つまりプロジェクトメトリクスの使用に重点を置く。
とのこと。
それ以外のメトリクスはExpertレベルで主に取り扱うとのことで、より分析の難易度が高くなるのだろう。
収集の自動化
メトリクスのレポートやメトリクスの集計に要する時間を短縮するために、生データからメトリクスを算出するまでを極力自動化すると良い。
ここは肝の一つだと思う。
いかにリズムよく（効率よく）実施できるかで、メトリクスの収集分析が継続的に実施できるかに影響すると思う。
具体的にどうすればよいか、まずは自分の考えを以下に書き出してみる。
テストケースに対する消化数や故障発生数・解消数などを収集し、テストの収束具合を判断しようとした場合、テストケースをExcelで管理していたら基本的には回らない。担当者に指示しても忙しいと漏れてしまいがち。そのため、テストケース及び結果投入にはシステムを用い、自動で分析させるのが吉と考える。
Redmineをカスタマイズして目的に応じた収集が可能なようにすることも良いように思うが、テストケースを１件１件登録するとかは無い（手間がかかりすぎるし参照しづらい）ため、基本的には専用ソフトの導入を検討したほうが良い。
ということで、テストケース・故障を管理し、メトリクスを収集→できれば自動的にレポート作成までこなすツールを調べてみた。
バグ密度・テスト密度を評価するのはもう古い？
・・・早速ちょっと横道にそれるが気になる記事があった。
昨今、バグ密度・テスト密度を評価するのはもう古いとのこと。
メトリクスを収集→計画されたバグ密度・テスト密度内にあるかどうかを評価するという手法が昔からあったが、それは土台（フレームワーク・人・開発手法など）がそろっている前提で成立するものであり、それが日進月歩で変わる現代において適用しづらい、と理解した。（なるほど）
代替する評価方法として、
①観点カバレッジ
プロセス（「何件テストをしたのか」より、「どのようなテストをしたのか」）の方が品質への寄与が大きい
→テスト観点を軸とし、その網羅性を確認
→プロセス品質は確認できるが、その妥当性は確認できない
②DDPモニタリング
DDP（Defect Detection Percentage：欠陥摘出率）
算出方法は以下の通りで、すり抜けバグが増えると値が下がる
DDP = n / n + x
ｎ：測定対象のプロセスで摘出したバグの数
ｘ：測定対象のプロセスですり抜けた摘出したバグの数）
観点カバレッジを実施していればDDPモニタリングで品質不安定となることはまれなため、観点カバレッジに時間をかけすぎないのがポイント。
CAT（Shift社）
良さそうなところ：
プロジェクト・工程別に登録するわかりやすさ
テスト項目をExcelライクで入力・Excelで入力したファイルのインポート・CSV出力
レポートなどが見やすそう
Redmineと連携できるとのこと（具体的な形が分からない）
オンプレあり
日本企業でありサポートを受けやすそう
確認したいところ：
実際の使いやすさ・わかりやすさ（理解のしやすさ）
カスタマイズのしやすさ
Redmineとの連携がどのようにできるか
Qangaroo
同様に良さそうだが、オンプレなし・・・残念
Quality Tracker（バルテス社）
これもよさそうだけど、オンプレ梨・・・残念
一度、CAT（Shift社）を試してみよう。
この記事が気に入ったらサポートをしてみませんか？