この記事は、ソフトウェアテスト Advent Calendar 2019の10日目の記事です。
qiita.com
前の記事はこちら。
halspring.hatenablog.com
9月にいくつかテストマネジメントツールについての勉強会に参加して、考える機会が多かったので、ちょっとアウトプットしてみました。参加したイベントはこちら。
connpass.com
テストマネジメントツールとは
テスト管理ツールは、主にテストケース、テスト実施結果（OK/NG/再実施など）、進捗、実施履歴などをWebで管理するツールです。要件管理はあるものとないものがあります。呼び方は「テストマネジメントツール」だったり「テスト管理ツール」と呼ばれていたりします。
導入時に考えること
テストマネジメントツールに限らず、ツール導入の際にはいくつか事前に考えておくべきことがあります。
- ツールで解決したい問題は何か？
- ツール導入でメリットは得られるのか？（デメリットの方が大きくなることはないか？）
- ツールが課す制約がこれまでのテストのフローを妨げる場合、それを許容できるか？
- 導入時には「ツールで解決したい問題」に目が行きがちですが、「ツールが課す制約」についても考える必要があります。これについては後で述べます。
- コストはどのくらいか？
- 初期費用や月額費用
- 導入にかかる教育コスト
- 運用コスト（手順を整えたり、オンプレやOSSの場合は自前でメンテナンスするコスト）
導入してメリットがある条件
ツールのメリットを享受するための前提はあまり触れられてないなと思ったので、自分なりに整理してみました。なお、テストマネジメントツールを使わない場合、テストケースの管理はExcelやスプレッドシートで行われることが多いので、比較対象はスプレッドシートとします。
複数人で使用すること
利用者が一人であるなら、次の理由からスプレッドシートでよいと思います。
テストケースの再利用を前提としていること
テストマネジメントツールは、テストケースの「普遍的な部分（実施手順、確認内容など）」と「テスト毎に毎回変わる部分（実施予定日、実施予定担当者など）」を分けて管理できます。普遍的な部分を資産として持っていて、そこからテスト実行ごとに「テスト毎に毎回変わる部分」を付加して、「テストインスタンス」を生成するイメージです。湯本剛（@yumotsuyo）さんの資料の説明が分かりやすいので、引用させてもらいました。
テストケースを再利用することを前提とすると、テストマネジメントツールの恩恵を受けやすいのは継続して開発、リリースする案件で使うことだと思います。条件に合う案件は、自分の観測範囲では自社サービス、ツールの開発案件が多い印象です。
単発の案件であっても、同じような案件が複数あるのであれば、観点とか項目といったナレッジの蓄積を目的として使うのは意味がある気はします。
ツールが課す制約を許容できるか
制約というちょっと強い表現を使いましたが、ツールを導入することによって今までと作業フローが変わったり、不便なことが出てきたりするが、それを許容できるか、という観点です。これ以下の内容は、私の主観が強いので当てはまらない場合もあると思います。
前提
私が触れたことのあるテストマネジメントツールは、Squash TM、TestRailの2つ、あとはKazu Suzuki（@kz_suzuki）さんのブログでPracti Testを少し眺めたくらいです。
www.kzsuzuki.com
そのため、それら2つ(+1つ)をベースにして、スプレッドシートでの運用と比較しています。
スプレッドシートでのテストケースの運用時には、「ID、テストケース名、手順、期待結果結果、実施予定日、実施予定担当、実施結果」を1行で管理しているものと仮定します。
テストケースの一覧に見るテストマネジメントツールとスプレッドシートの比較
テストマネジメントツールとスプレッドシートでは、設計の思想が違います。テストマネジメントツールは、もちろんテストに関するあれこれ（要件、テストケース、実行結果など）の管理を目的として作られたツールですし、スプレッドシートは表計算を主眼として作られたツールです。
テストマネジメントツールとスプレッドシートでテストケースを作成する場合、テストケース一覧の表示内容、運用に差が顕著に出ていると思ったため、次の項目について比較してみました。比較したのは、「前提」でスプレッドシートでの運用時に管理対象として仮定した「ID、テストケース名、手順、期待結果結果」とプラスアルファです。「実施予定日、実施予定担当、実施結果」については、テストマネジメントツールの場合、テストケース作成の段階で管理しないため省略しました。
| 比較対象 | テストマネジメントツール | スプレッドシート |
|---|---|---|
| ID | 〇 | 〇 |
| テストケース名 | 〇 | 〇 |
| 優先度 | 〇 | △ |
| 手順 | × | 〇 |
| 期待結果 | × | 〇 |
| 表示項目のカスタマイズ | ツールで表示対象に設定できる項目のみ | 追加が可能（組織でテンプレートとして定められている部分を除く） |
| 一覧に表示できる行数 | 制限あり（TestRailでは2000行だった） | スプレッドシートの限界までは理論上可能 |
凡例：
〇：デフォルトで表示対象、記載対象とされている
△：デフォルトではないが、多くの場合表示/記載あり
×：なし（表示できる対象として設定されていない）
補足：テストケース名から参照的に手順、期待結果を表示することは可能。ただし選択した1ケースのみ。
テストマネジメントツールの導入で変わる部分
スプレッドシートでの運用している時と比べると、変わる点は次のようなものがあると考えています。
- 手順、期待結果をレビューする場合、テストマネジメントツールではテストケースの一覧上でできない
- 手順、期待結果を含めたCSVなどでのエクスポートは可能
- ただし、ツールによってはテストケース名の一覧と手順・期待結果の一覧は別のシートで出てきて多少見づらい
- テストケース名で、テスト内容の分かりやすいサマリを表現することが求められる
- 期待結果が一覧上でも見えていれば、テストケース名を多少適当につけていても、テストの意図を補完できたが、それができなくなる
- スプレッドシートでもテストケース名を分かりやすくつけていた場合は従来と変わらない
- 一覧に表示する項目をカスタマイズできない
- スプレッドシートだと、運用上の良し悪しは置いておいて、欄外にメモ欄など追加できたが、ツールではできない
上にあげた例では、スプレッドシートでの運用に問題があるものもありそうですが、ツールの導入によって、今まではできていたことができなくなることは考慮する必要があります。
まとめ
テストマネジメントツールは、ツールのメリットを出せる状況下で使えば、効率化を素晴らしくサポートしてくれるものだと思っています。ただ、ツールの導入には利点だけでなく、従来はできていたことに制約がかかるパターンがあるので、制約を考慮した上でもなおツール導入のメリットがあるのかは考える必要があります。
