この記事は
この記事は、主にテストプロセスにおける「モニタリングとコントロール」について記載しています。
また、それに付随して「テスト設計」についても多少の記載をしています。
これまで様々な書籍や資料を参考にしながら、私が試してみたテストの進捗管理について、現時点でまとめられる内容を記載します。
当初の課題感
まず大前提として、開発とテストの工数は比例しません。
開発があっという間に終わる作業でもテストは長時間かかることがありますし、逆に、開発が長時間かかってもテストはすぐに終わってしまうこともあります。
よって、開発とテストで工数管理は分ける方が良いのですが、以前私が参加したプロジェクトでは、それがなされていませんでした。
プロジェクト管理ツールがチケットの重みづけからバーンダウンチャートを自動生成するのですが、その重みづけは開発のためだけに利用されていました。
そのため、軽いチケットがいつまでもテスト完了しないと、いつ終わるのかプロジェクトマネージャーが気を揉んでしまう訳です。
そこで、テスト進捗については、QAチームでGoogleSpreadSheetを使って独自にバーンダウンチャートを作成し、トライアルで運用してみようということになりました。
そのほうがプロジェクトマネージャーにも進捗の説明がしやすいと思いました。
テスト進捗のバーンダウンチャート
テスト進捗のバーンダウンチャートを作るにあたって、まずは下記の２つの方法を同時に運用しながら比べてみることにしました。
・テストケースの残数で管理する方法
・チケットごとに重みづけをする方法
運用してみて感じたそれぞれの特徴から、考えられる＜長所＞と＜短所＞を挙げます。
テストケースの残数で管理する方法
テストケースを消化したらバーンダウンする管理方法です。
＜長所＞
・「１ケースあたり何分」で計算できるので、詳細な工数予測ができる。
・テストケースが全て準備完了してからテスト実行に入りたいので、開発フェーズとテストフェーズが明確に分かれているウォーターフォールモデルで導入しやすい。
・テストケースを企画担当者や開発担当者にレビューしてもらい不足分を補った上で工数を計算できるので、発足したばかりのプロジェクトや、安定性や安全性に厳しいプロダクトにも導入しやすい。
＜短所＞
・バグチケットが起票されてもすぐにチャートに反映されない。 （テストケースを追加するまでバーンアップしない）
・テストケースの粒度を揃えないと信頼度が下がる。
・テスト設計者の人数が多い場合、テストケースの粒度を揃えるための認識すり合わせやトレーニングなどの準備に、さらなる工数が必要
・テストケースの粒度を揃えるために、テスト実行者の自由な発想が阻まれるため、探索的テストでは運用しづらい。
※テストケースが増えたらどうするか
のちに、テストフェーズ中にテストケースが増えた場合にチャートにも簡単に反映させたいと思い、テスト設計に次のようなルールを追加しました。
・テストフェーズ中に増えたテストケースは、優先度を未設定にすること
これにより、優先度が未設定のケースをカウントして総数に加算し、増加分をいつでも把握することができるようになりました。
チケットごとに重みづけをする方法
チケットステータスが「テスト完了」になったらバーンダウンする管理方法です。
＜長所＞
・チケット（バグチケット含む）が新たに起票されたら、すばやくチャートに反映できる。（重みづけを設定するだけですぐにバーンアップする）
・セッション時間でテスト単位を区切った探索的テストでも運用しやすい。
・上記の理由により、アジャイル開発で導入しやすい。
＜短所＞
・テストケースの残数で管理するよりも、工数予測が大雑把になる。
・経験や理解が浅いと、チケットの重みづけを誤るリスクが大きい。
・上記の理由により、発足したばかりのプロジェクトや、安定性や安全性に厳しいプロダクトでは導入しづらい。
※バグチケットの起票数を把握するには
のちに、バグチケットの起票数を日毎に把握したいと思い、チャートを次のように改修しました。
・日毎起票数を棒グラフで表示する
これにより、テストケースの消化率とバグの累計で把握する信頼度成長曲線とはだいぶ雰囲気が異なるものの、テストが理想どおり前半に多くバグを検出し、後半はバグ検出のペースがゆるやかになっているか把握できるようになりました。
※「理想どおり」というのは、バグの検出が前半に多ければリリース日まで余裕があり、修正するための時間を確保できるため、安全な開発を支援できると考えているためです。
さらに、起票したバグチケットについて、重篤度の内訳を把握したいと思うようになりました。
重篤度が高いバグを前半に検出できていれば、より理想どおりだと判断できるためです。
そこで、バグチケットの起票ルールに次の内容を追加しました。
・バグチケットに重篤度を設定すること
そして、重篤度によって棒グラフを色分けすることにしました。
これにより、後半に起票数が増えても軽ければ問題ないと判断することができるようになりました。
まとめ
課題の把握とトライアル運用の開始から約1年半ほど経過した時点での内容を今回まとめてみました。これからも様々な文献を参考にしながら、より良いテスト進捗の管理方法を模索していきたいと考えています。
続きはいつか、別記事で書くかもしれません。
参考資料
JSTQB Foundation第4版 シラバス2018対応
↑テストプロセスの図をそのまま使わせていただきました。
『現場の仕事がバリバリ進むソフトウェアテスト手法』高橋寿一/湯本剛
↑テスト実行数の推移グラフを参考にしました。
『ソフトウェアテスト見積もりガイドブック〜品質要件に応じた見積もりとは』独立行政法人情報処理推進機構ソフトウェアエンジニアリングセンター編
https://www.ipa.go.jp/files/000005132.pdf
↑信頼度成長曲線を参考にしました。
『この１冊でよくわかるソフトウェアテストの教科書』石原一宏/田中英和
↑テスト実施のモニタリングを参考にしました。
freeeQAにおける品質指標の改善の話
https://developers.freee.co.jp/entry/quality-metrics
↑「重篤度」という言葉と、積み上げ棒グラフのヒントをいただきました。