これはQiita Engineer Festa 2024のキャンペーンテーマである「そうだ！TestRailを使ってみよう！！」 の記事です。
はじめに
TestRailはブラウザ上で動作するテスト管理ツールです。
最初にこのツールを見た瞬間、真っ先に「あのレガシープロジェクト1のテスト管理用エクセルもどうにかできるのかな？？？」と思いました。
該当のプロジェクトは長期の運用に加えて事情が複雑だったこともあり、テスト管理用のエクセルは地獄のようになっていました。書ける範囲だと以下のような状態だったと記憶しています。
- 長い時間とたくさんの人の知見が集積されたマクロにより、テスト項目の組み合わせが自動生成される（されない機能もあるので、それは人力で作る）
- 生成された項目から（プロジェクトを知っている人なら納得できるが、初見だとまずわからない判定基準により）テスト項目の要不要を選り分けている
- 機能ごとにテスト項目表の「確認内容」部分が細分化されている
かなり簡易に再現するとこんな感じのはずです。
実際は操作部分の箇所と確認項目部分はもっと複雑ですし、これが数百行あります。再現している最中に胸が苦しくなってきました。
マトリクス表ともデシジョンテーブルとも違うと思っているのですが、これは…何表なんでしょう…。
なお、この表は開発工程で必要になるもので、開発部隊が自分たちで作った機能を自分たちでテストするためのものです。QAが使用するものではありません。
エクセル管理による限界
よくありがちなのが、最新版がわからないとか、複数人がローカルで編集してしまったからエクセル同士のマージ作業で心が死ぬとかでしょうか。思い出して「あれはほんと無駄な時間だったな」としみじみしてしまいました。
ぱっと見ても進捗率もわかりにくいし、テスト項目のやり残しがあったりして、管理が厳しいと感じることはとても多かったです。
TestRailを使ってみる
一番大きな単位がプロジェクトで、その下にテストケースと、テストケースの集合であるテストスイート、テストの実行結果であるテストランが管理されています。
最初説明を見ずに始めたので字面が似すぎて混乱したのですが、これさえ頭に入っていれば問題なく使い始められると思います。
テストの一覧もすごく見やすいです。
ブラウザからアクセスすれば常に最新版ですし、複数人で編集してもコンフリクトすることはありません。
あとすごく良いなと思ったのが、サンプルプロジェクトに作業負荷を出しているグラフがあったことです。
これは自分がプロジェクトに所属している時にめちゃくちゃ欲しかった機能です。エクセルだと誰が何のテストをどのくらいしているのか全然わからなかったので、手伝ってほしくてもリソースの空きがわからず全員疲弊しているというやばい状況でした。
良い！と感じたところ
作業負荷グラフ以外にも、デモサイトを使ってみて良いと感じたところを列挙します。
テストの修正履歴が残る
テストケースごとに、いつ、誰がどこを変更したのかすぐわかるようになっています。
仕様変更や機能追加により、確認項目の変更や、テストの前提条件を変更することがあります。このような場合、履歴を備考欄等に残すのが最適ですが、テストケースに変更がある時＝作業が他にも山程ある時なので、「後で書く」のまま放置されがちです。
修正履歴がわからないと、後々見返した時にテストケースの正しさを確認するのが困難になりますが、TestRailだとテストケースごとに履歴がわかるのですごく良いです。欲を言えばGitのように変更時にコメントが残せるとさらに便利だと思いました。
テストスイート・テストランに説明を記載する欄がある
きちんとしたテスト計画書であればいざ知らず、自分たちで作った部分を自分たちでテストする時は「なにを確認するためのテストなのか」「どのタイミングで実施するべきなのか」「なぜこのテストを実施したのか」といった共通認識のような箇所はアンドキュメントになりがちです。テストスイートごとに目的が文章として残せるのは地味だけれど嬉しいと思いました。
Markdownが使える
一部フィールドにMarkdownが使えます。
期待する結果で試してみました。
期待通りcode になりました。
エクセルにありがちな「確認内容の項目にレスポンスボディが書いてあるが、読みにくい」という問題が解消できます。これはむちゃくちゃ嬉しいです！ただ、リスト記法と合体させてコードブロックを使おうとするとうまくいかなかったので、改善を期待しています。
厳しい…！と感じたところ
逆にこれは厳しいと感じたところを列挙します。
フォーマットが結構ガチガチ
フォーマットに統一性が持たせられるため、テスト対象ごとに確認項目やテストの粒度が異なるといった問題は確実に減ります。逆を言うと融通が利かないので、最初に述べたエクセル管理表くらい複雑になるとテストケースが作れなくなります。
複雑な表は作れなくても良いのですが、もう少し項目の細分化ができれば嬉しかったです。
デモサイトだから難しいのかも…と思ったのですが、他のレビューを見ても「複雑な表は作れない」ということは言及されていたので、TestRailの仕様でそうなっているようです。
テストケースとテストスイートとテストランが横に並ぶと字面で区別がつかない
誇張抜きでTestRailを使う上で一番大きな障壁はこれだと思っています。
慣れの問題ではあるのですが、最初はぱっと見て区別がつかないので使っていてむちゃくちゃストレスが溜まりました。
TestRailのレビュー記事を見ると、用語が難しいと書いている方が何人かいたのですが、字面を変えるだけでもだいぶ印象が違うと思います。
テストスイートはJSTQBのテキストを読んだことがあるか、JUnitあたりで使ったことがある人でないと混乱しそうです。
アクティビティでは色分けされていてわかりやすいです。
テストケースを連続で追加する時に画面遷移がある
テストケースは連続で追加できるのですが、追加するたびに画面遷移が発生するので、前に作った項目と見比べられないのと、待ち時間がストレスになります。エクセルは全部同じブックで完結するので、それと同じ感覚でテスト項目を作ろうとするとつらいです。
結局あのレガシープロジェクトのテスト管理はTestRailで救えたのか
救えなかったと思います。
TestRailを使っての印象ですが、Webアプリやスマホアプリといった、提供する機能が明確なソフトウェアのテストとは非常に相性がよいと感じました。一方で、今回のように機能が複雑で、フリーフォーマットでないとテスト項目の作成が難しい場合2には向いていません。
- 複雑な表がフリーフォーマットで作れる
- 表を操作するスクリプトを書ける、かつ会社内外で広く使われている
という条件を満たそうとすると、どうしても秘伝のエクセルに頼らざるを得ません。
当時TestRailと出会っていたとしても、限られたリソースで脱エクセルではなく、テストの自動化を進めるほうに軍配が上がったと思います。
どんなプロジェクトなら向いているのか
新規プロジェクトや、テスト項目をTestRailに落とし込めるプロジェクトであれば、是が非でも採用を検討すべきだと思います。将来に負債を残さないという点と、テスト項目の管理のしやすさでは圧倒的にTestRailが良かったです。
おわりに
かなり色々書いたのですが、使い心地がとても良かったのと、今まで知らなかったサービスを知ることができたので、この記事を読んでくださった方はぜひデモサイトを触ってみてください。