本記事は ベリサーブ Advent Calendar 2021 の24日目の記事です。
テスト管理におけるとある概念について、調べたり考察したりしました、というポエムです。クリスマスの夜の暇つぶしにでもなったら幸いです。もし何か誤り等ありましたら、コメントでその旨ご指摘いただければと思います。
突然ですが
読者の皆さま。
複数のテストケースを束ねてできた情報、概念
というと、何を想像しますか？
結論から言うと、ISTQB/JSTQB用語集上で定義されたものとしては、おそらく以下のものが該当しそうです。
- テスト手順
- テストスイート
- 正確にはテストケースを束ねてできたテスト手順を、さらに束ねてできたもの、なのかな？
テストケースのグルーピング
今更自己紹介ではありますが、私、株式会社ベリサーブで以下のツール群の開発マネージャーをしております、きんぢ、と申します。
上記のうちのひとつめのツール、QuailtyForwardはいわゆるテスト管理ツールに分類されるツールです。テスト管理ツールの最も基本的な機能はテスト実行の進捗や品質状況の可視化ですが、テストケースなどの成果物の資産管理も、テスト現場にとっては重要な機能かなと思います。
さて、テストの資産管理やテストの計画を立てる際、テストケースのグルーピングを考える局面が2つあります。
- 大量のテストケース自体をデータとして保持する際に、どうグルーピング・整理するのか？
- テスト計画時に、どの単位・順序でテストケースをまとめて、テスト実行者にアサイン・管理するか？
前述のテスト手順やテストスイートは、どうやら後者の文脈で作成される成果物を意味しており、逆に前者の資産管理の文脈で、テストケースを管理するカタマリ、に該当する概念はISTQB/JSTQBには定義されていないようです。
スプレッドシートによるテスト管理
専用のテスト管理ツールではなく、Miscrosoft Excelに代表されるスプレッドシート系のツールでテスト管理をしているシステム開発プロジェクトはたくさんあると思います。スプレッドシートを用いてテストケースを管理する際、最も基本的なアプローチは、表の1行で1テストケースを表現し、それが縦に複数並ぶ形でテストケースが羅列され、そしていい感じの単位でシートやファイルを分けることでグルーピングされて管理されるやり方ではないでしょうか。
この場合、ファイル管理されている時点で、それがそのまま前述の資産管理の文脈でのグルーピング・整理になりますし、一方でテスト実行時にわざわざテストケースのかたまりを組み換えるのは非効率であるため、同時にテスト実行時に活用されるグルーピングでもあることが多いでしょう。
QualityForwardによるテスト管理
次に、当社のQualityForwardの場合を見てみましょう。といっても、話は単純です。QualityForwardは開発コンセプトとして、スプレッドシートでテスト管理をしているプロジェクトが移行しやすいよう、スプレッドシートの1シートをそのまま1「テストスイート」という単位でインポートし、その後のテストケースの編集やレビュー、計画や実行もこの単位で実施していただく設計となっております。
つまりQualityForwardは、テストケースのグルーピングについて、スプレッドシート利用時と同様、2つの文脈を同時にテストスイートという単位で管理をします。
前述のとおり、ISTQB/JSTQBにおいては、テストスイートはテストケースではなく、テスト手順をグルーピングしたもののようなので、厳密にはQualityForwardが用いているテストスイートの定義とはズレがあります。
他社製品によるテスト管理
では、他社のテスト管理ツールでは、これらはどのような形で管理されるのでしょうか？今回は例として、MICRO FOCUS社のALM/Quality Centerと、Gurock社のTestRailについて、チームメンバーに調査をしてもらい、結果として以下のようになっていました。
- どちらのツールも、テスト資産管理とテスト実行の文脈では、異なる概念でグルーピングをする設計となっている。
- Quality Centerの場合、後者は「TestSet」、前者は「Subject」というツリー構造のフォルダにケースを1件1件ファイル感覚で保持する。
- TestRailも同様、後者は「TestRun」、前者は「section」という名前で、やはりツリー構造のフォルダ管理。
以上からわかるQualityForwardの特長
以上から、QualityForwardと代表的な他社のテスト管理ツールとは、テストケース資産管理の考え方で明確な違いがあることがわかります。
QualityForwardはスプレッドシートの考え方を踏襲し、テストケースの資産管理とテスト実行時とで、同じグルーピングでテストケースを扱います。したがって、テスト実行ごとにテストケースの順序や組み合わせを柔軟に組み替えることは困難ですが、同じ単位で問題ないシーンにおいては、テスト計画時の効率がよいと考えられます。
一方、他社ツールは管理単位が異なるため、テスト計画時に都度テストケースを組み合わせてテスト手順を作成する必要があります。しかし、それによって、実行時のコンテキストにあわせた柔軟なテスト計画が実現可能です。
まとめ
- テストケースのグルーピングを扱う際、2つの観点がありそう。
- ISTQB/JSTQBでは、テスト実行文脈の概念の定義はあるが、テスト資産管理の文脈での概念は特に定義されていなさそう。
- テスト管理ツールには、これら2つの文脈で、同じグルーピングでテストケースを管理するものと、文脈ごとに異なる仕組みでグルーピングするものがある。
- どういうシーンにおいて、どちらのアプローチがより適しているかは、今後もっと深く考察したいと思う。（力尽きた）
そんなところです。