テスト管理ツールの CAT の進捗管理や分析の見方を運用例を用いて紹介したいと思います。
※なお、テスト項目やテスト結果は、本記事用に作成したサンプルです。
参考：テスト管理ツール CAT の分析機能がリニューアル
参考：テスト管理ツール CAT を利用したテスト実施の運用例
進捗管理
プロジェクトを選択後、上部メニューの「進捗管理」をクリックすると、テスト消化の進捗グラフを見ることができます。
グラフ上部にある凡例をクリックすることで、グラフ要素から追加・削除ができます。
このグラフの例ですと、「ケース数」やテスト結果の「OK」「NG」などが非表示になっています。
この進捗グラフを見ると、6/3 辺りからテストの消化スピードが鈍化していますね。
なぜテスト進捗がスローダウンしてしまったのでしょうか。
プロジェクトとしては原因を追究して是非とも改善したいところですね。
分析
障害レポートの一覧を見ると（上部メニューの「課題管理」）、6/2 辺りから優先度の高い障害が多く発生しています。
レポートの優先度を決定する要因はいくつかあると思いますが、特に重要なのは他のテスト項目の消化を阻害する要因となるものです。
恐らくこれら優先度の高い障害が、テストの進捗を妨げてしまっているのでは、と推測できそうです。
機能を見ると売上管理やマイページ、カート機能辺りの不具合がこれにあたりそうです。
続いて上部メニューの「分析」をクリックして、障害件数の分布などを見てみましょう。
デフォルトでは重要度別の障害件数と機能とのクロス集計のグラフが表示されます。
カート機能の障害件数が突出していますね。
重要度も他の機能と比べて非常に高いです。
これについては以下のような要因が考えられます。
a) 実装ステップ数が多い
b) 実装の難易度が高い
c) 前工程のテストが不十分
a) について検証するために、グラフ表示の「課題数/Kstep」ボタンをクリックし、ステップ数当りの障害件数を見てみます。
カート機能はステップ当りの故障率が若干高めですが、a) が直接的な原因というわけでもなさそうです。
それよりも売上管理機能の故障率の高さが気になりますね。
売上管理機能とカート機能に b) c) 辺りの問題点があるように見えます。
b) は逆説的には担当した開発者の技術レベルが低かったと考えることもできます。
念のため「メンバー」タブをクリックし、開発者ごとの障害件数を見てみます。
カート機能を担当した developer03 さんに重要度の高い障害が集中しています。
developer01 さんも障害数は同じくらいですが、重要度との兼ね合いから developer03 さんの問題が大きそうです。
例えば障害件数の少ない developer02 さんもカート機能に携わっていれば、このグラフから developer03 さんのスキルに問題があるかもしれないという推測ができますが、カート機能を developer03 さんだけが担当していた場合は、カート機能に問題があるのか開発者に問題があるのかはこのグラフからはわかりません。
上記のグラフは分類を「信頼度分析」、表示種別を「テスト実行日」に選択したものです。
やはり 6/2 辺りから重要度の高い障害が出始め、徐々に全体を占める割合が多くなっていることがわかります。
詳細な分析は「課題管理」画面で
グラフなどで視覚的に確認することはできませんが、「課題管理」の表示カラムを工夫することで、もう少し詳細な分析をしてみましょう。
各カラムのヘッダ部をクリックすることで、そのカラムのソート順変更や他のカラムを追加することができます。
上部メニューの「課題管理」をクリックして障害レポート一覧画面に移動し、見たいカラムを選択します。
まずは「カート機能」でフィルターしてみます。
障害原因の中に実装の難易度と関係のありそうな「技術不足」という項目があるのでフィルターしてみます。
（全体の割合を見たいので機能のフィルターははずします）
技術不足が原因となる障害はマイページとカート機能だけですね。
やはりカート機能は他の機能と比べて技術スキルが求められるコンポーネントであったようです。
（本当はこの辺りグラフで視覚的に見たいですね）
カート機能でもう一つ気になる点は、混入工程の項目に設計工程が散見できるところです。
カラムのグルーピング機能を使って混入工程ごとに分類してみましょう。
設計工程での不具合が、見事にカート機能に集中していますね。
カート機能は設計工程が十分に行われていなかったのではないでしょうか。
developer03 さんの問題というよりも、上流工程の方に問題があったようです。
ということで、技術的に難しいコンポーネントについては、「設計工程を十分に行い、レビューもしっかりと実施しよう」という課題が見つかりました。
あと、developer01 さん担当の売上管理機能の故障率が高かったのですが、developer01 さんでフィルタしてみると、
うーん、developer01 さん、単体テスト足りないんじゃないの？ という結果が見えてきました。
ということで、developer01 さんの単体テスト工程の見直しが行われることとなりました。
参考： 単体テストのテスト項目の観点
あくまで一例ではありますが、以上でテスト管理ツールを利用した障害分析の方法の紹介は終わりです。
やはり、「e5: 障害区分」や 「e6: 障害原因」、「e7: 混入工程」、「e8: 発見すべき工程」辺りはのちの分析に非常に役立ちますので、面倒でも障害レポートのデータとして保存しておくべきかと思います。
参考： 障害レポートの内容
ちなみに課題管理の一覧はCSV形式でのダウンロードが可能なので、そのまま障害管理台帳として保存することができます。
課題一覧の表示カラムの工夫で分析した部分も、このCSVをエクセルでグラフ化すればもっと視覚的にわかりやすくなるかと思います。
参考までに本サンプル運用の結果を CAT でダウンロードした障害管理台帳を置いておきます。
また、分析画面はログインアカウントを持っていない第三者に対して公開の URL を作ることができます。
下記 URL をクリックすると、本サンプル運用の実際の分析画面を参照することができます。
コメント