本エントリーは VeriServe Advent Calendar 2022 の18日目の記事となります。所属企業の企画ということで、昨年の記事 に続き、本業のメインではテスト管理ツール QualityForward を扱っているので、それに関連してテスト管理の小ネタをお届けします。
テスト管理ツールの利点
ソフトウェアテストの現場では、まだまだテスト管理の手段としてExcelやGoogleスプレッドシートのような、スプレッドシートツールでテストケースやその実行結果を管理しているところが多いかと思います。これらのツールは非常に有用ではあるのですが、プロジェクトの大規模化や、リリースサイクルの高速化によるテスト頻度の増加に伴い、以下の問題が大きくなってきます。
- テスト結果の集計や、集計マクロのメンテナンス作業に時間がかかる
- テストケースの変更差分の確認・レビューに時間がかかる
- 修正・実行したいテストケース探しに時間がかかる
世の中にある様々なテスト管理専用ツールはこうした問題にそれぞれのアプローチで対応しています。特に上記のひとつめの問題に対しては、各ツール様々なビルトインレポートを提供しており、誰かが1件でもテスト実行をしたらその結果が即時レポートに反映されます。
テスト実行結果数のレポート
さて、本日は小ネタ記事ということで、さらにぐっと話題をしぼって、表題のとおり テスト実行結果数 のレポートの仕方について考察をします。テスト実行の進捗管理としては、まずは予定実行数に対して実際に実行した件数をみるのがテッパンでしょう。ただ、実行件数が増えていっても、たとえばほとんどテストがfailしていたらプロジェクトとしては決して順調な状況とはいいがたいです。したがって、パッと見でテストの概況を知るには、実行した件数の結果の内訳も含めて可視化することが重要です。多くのテスト管理ツールでは、日次のテスト実行結果数を、その結果の内訳で色別で積み上げて可視化するグラフを標準で提供しています。
テスト結果の扱い方と積み上げグラフの見え方
さて、テストケースそのものと、その実行結果のデータの扱い方はツールによって考え方が異なります。前述のグラフは、このデータの扱い方によって見え方が大きく変わってきます。
パターン1 : 上書きタイプ
テストにおいて一発で全件がpassするに越したことはないですが、残念ながら現実にはそうなることは稀で、たいていfailするケースや、そもそも実行できなくて進捗しないケース（block）が出て、それらはプロダクト修正後に再テストすることとなります。再テストしたときの結果の扱い方のひとつは、すでにfailした結果に2回目以降の結果を上書きしているスタイルです。その場合、テスト実行結果数の推移はたとえば以下のようなイメージになります。
1回目の実行までは右肩上がりに増えていき、それ以降は上書きによって結果が書き換わるだけのため累計数に変化はありません。
パターン2 : 別実施タイプ
もうひとつのアプローチは、テストケースとテスト実行を1:nの関係でモデリングし、2周目以降のfailやblockのケースの再実行は、1周目とは別の件数として扱うパターンです。この場合、実行数は最後まで右肩あがりで増えていきます。
考察
上記に2パターンのグラフはそれぞれ以下のようなメリット・デメリットがあります。
| メリット | デメリット | |
|---|---|---|
| パターン1 : 上書きタイプ | 特にテスト終盤にて、「すべてpassしている状況」がパっと見すぐわかる | 2周目以降、リグレッションテストなども実施しているときに、pass数とfail数が同じときに相殺され進捗状況が可視化できない |
| パターン2 : 別実施タイプ | どのフェーズでも日次の進捗概況を確実に把握できる | 特にテスト終盤にて、「残っているfail数」を把握しづらい |
グラフとしてはどちらがいいということはなく、それぞれデメリットを補完するために別のチャートと組み合わせて概況を見たり、もしくはこれら2パターンを両方出せるようにするのもいいかもしれません。（後者のグラフのデータがあれば、前者のグラフを出すのは可能）一方で、前述のとおり、データの持ち方としては別実施パターンで保持しておいたほうが小回りがきくため、データ管理の仕方はこちらのほうが確実によいでしょう。
おわりに
以上、テスト実施結果数の推移レポートに仕方に関する小ネタでございました。スプレッドシートツールでテスト管理されている方は独自レポートの検討のインプットに、またテスト管理専用ツールを検討されている方は、ツール選びの際のテスト結果の管理の仕方やレポート機能を比較する観点としていただければ幸いです。