※本エントリーでの「不具合」は、テスト中に検知されたものだけでなく、リリース後に検知されたものも含みます
#この記事の概要
- 読了までの時間：4分
- リリース後に発生する不具合の削減を進める上で、どんな対策が有効か考えるために、不具合の分析を行うことが多いのですが、その中で可視化してよかった思うメトリクス表の例をいくつか紹介できればと思います
メトリクス表の一例
- 以下で、それぞれのメトリクスについて、どのようなシチュエーションで使えるのか、また使用時の注意点を書いていきます
#発生箇所と不具合件数
利用シチュエーション
- 不具合は具体的にどの辺りで多いのか？を知りたいとき
- こちらは頻繁に使われるメトリクス表かもしれませんが、発生箇所を特定する際に有効です
注意点
- 発生箇所の粒度は、あまり細かすぎても傾向が見えづらくなるので、画面単位くらいがちょうどいい気がします
#各工程と不具合件数
利用シチュエーション
- テコ入れすべきはテストケースなのか、開発の実装なのか？を知りたいとき
- フェーズごとに件数を可視化することで、がんばってテストでせき止めているところと、逆にテストが薄くて不具合が漏れ出ている箇所が見えてきます
- テスト中の不具合が多い場合は実装改善の提案を行ったり、逆にリリース後の不具合が多くてテスト中の不具合が少ない場合は、テスト項目の見直しなどのNextActionにつなげられます
注意点
- テスト中の不具合とリリース後の不具合で、発生箇所のラベルを統一しておく必要があります
#テストケース項目と不具合数
利用シチュエーション
- 実装品質の弱いところを、しっかりと補えるテストケースになっているか？を知りたいとき
- さらに、市場に出てしまうと影響の大きな不具合に絞って見ることで、リスク度合いに応じてテストケースが作られているかを確認することができます
- 列にテストケース項目ごとのテストケース数を追加することで、テスト粒度の強弱についても確認することができます
注意点
- テストケースの項目は、機能の重要度によって増減する傾向があるため、テスト内容もあわせて確認する必要があります
#さいごに
- 上記のメトリクスを使用することで、大きく以下3点につなげることができました
- 弱点機能/範囲のテスト強化および開発チームの再発防止導入
- テストケースの改善
- テスト工数の妥当性の見直し
- 今回ご紹介したメトリクスはあくまで一例で、現場ごとに組み合わせるメトリクスなども異なりますが、うまくデータを使うことでより効果的な改善アプローチにつながると思いますので、引き続き良いアプローチを模索していきたいです。