品質指標値の計測・集計

ライフイズテック１人QAのotkyskです。いつもブログをご覧いただき誠にありがとうございます。
今回はライフイズテックにジョインしてから計測・集計している品質指標値について投稿したいと考えました。

品質指標値とは？

一般的には「過去プロジェクトの実績データから「これくらいの規模であれば、これくらいのテストケース数を作成し、これくらいの不具合が出る傾向にある」という目安」と言われています。
ここでポイントなのは目安という事です。絶対値では無いという事を意味しているのかと考えられます。

弊社で計測・集計している品質指標値

バグ密度、MTBFの２つです。バグ密度はどれだけバグを出せれば良いか？という目安になり、MTBFは適切な工数でテストをできているか？という目安になると考え、計測・集計しています。

バグ密度の傾向

QAにジョインしてから１年以上、バグ密度を計測・集計してきて一度しか過去の実績から当てはまった事はありませんが、計測・集計し続ければ昨対比での比較が可能となり、計測・集計して有効だと判断しました。

特に案件の中で大型な規模である昨年3月のライフイズテック学校プロダクトの先生/生徒画面の刷新と、今年3月にリリースした先生/生徒画面の刷新とでバグ密度がほぼ同等である結果を得られました。要因ならびに背景は以下のように考えました。

• テスト仕様書のピアレビューの回数と時間がほぼ同じ

• 開発者はテスト仕様書をベースに実装をしていない（リソースの都合上）

• 打鍵する担当者が昨年、今年共に手慣れている担当者であった

よって、今後はおおよそのプログラム追加・変更分からバグの件数と修正確認工数の見積もりを事前にできるという事に繋げられます。

MTBFの傾向

MTBFの傾向としてはアジャイル開発で短期間でのテストという事もありながら高い数値は得られない（例外はある）ですが、前述したMTBFは適切な工数でテストをできているか？という目安になるという観点で見ると、ほぼ適切な工数でテストをできているとは考えられます。

前述したバグのおおよその件数からMTBFの平均値を当てはめる事で、バグの修正確認にかかる工数の精度が上がると考えられます。そして、テスト設計をして出来上がったテストシナリオの項目数から普段のテストシナリオの項目の消化ペースを当てはめてテスト自体にかかる工数とを足し算すれば、テスト全体でかかる工数、テスト期間に当てはめる人員配置ができるよう繋がります。

最後に

今回はライフイズテックで取り扱っている品質指標値とその傾向ならびに今後にどう繋げられるか？という事を発信しますが、品質指標値は他にもあり、JaSSTを筆頭に日々試行錯誤してテスト活動に有効なものとして使えるか永遠の研究課題となっています。

よって、私自身も品質指標値を継続して取り扱い、有利な活動に繋げられれば継続する、不利になってしまう前に別の指標値を取り扱ってみてとPDCAサイクルを回していきます。