テストケースの管理は、テスト自動化云々の前になんとかしておきたいところ。テストケースはExcel管理することが経験上多いですが、世の中にはもっと便利なものがあるだろうと思い、ブラウザベースでテスト管理できる「TestRail」を試してみました。さてさて、Excelを超えるのでしょうか？ 超えてみろ！
なぜテスト管理が重要なのか
テストケースの管理について、以下のような課題を多く経験しました。
- テストケースの追加や更新、その後の整理が難しい。行のコピペミスやマージ漏れ、同時更新でおかしくなったりファイルが壊れたり。マスタとなるテストケースをバージョン管理しながら育てていきたい。
- トラッキング情報を書き込みにくい。Excelのセルには表示限界がある。「5/31 藤原 XXXXX追加」とか書くのがとても面倒くさい。
- 過去のケースを検索しにくい。ファイル・フォルダに行って、過去の日付のケースを開いて、検索して・・・。を過去のケース分、繰り返す必要がある。
- ある修正でどのテストケースを選んだらいいかわかりにくい。今回1番解決したい問題はこれ。
前に実践アジャイルテストという記事を書いたのですが、そこではTwitterを想定して機能同士の関連性を図にした「テストマップ（仮）」を書いてみました。例えば機能ごとにこんな関連性があります。
フォロワー一覧を開いて、あるユーザをブロックすると、タイムラインからそのユーザのつぶやきが消える。
この場合、フォロワー一覧を修正したら、タイムラインもテストしといたほうがうれしいかもしれません。機能ごとの関連性は、テストの関連性でもあるので、「ここいじったらここもね」みたいなのが見えると、影響範囲を特定しやすくなります。だから、「どのテストケースを選べばいいか」をわかりやすくしたいのです。
これが簡単にできたら、ある程度の品質は担保できる気がするので、いい方法ないかなぁと常々思っていました。
TestRailのことはじめ
まずはプロジェクトを作ります。プロジェクトはサービスやシステムやアプリなど、ある程度の規模のあるシステムがよいとおもいます。
TestRailではプロジェクトの種類を選べます。
- Use a single repository for all cases (recommended)： 大抵の場合はこれで十分だそうです。とりあえずここでもこれを選んでおきます。
- Use a single repository with baseline support： 複数プロジェクトを平行してテストするためのプロジェクトです。ブランチを作れるのが特徴的。複数案件が走ることは多いので、もしかしたら、こっちのプロジェクトのほうがいいかもしれません。
- Use multiple test suites to manage cases： 昔のバージョンのTestRailはこのリポジトリタイプだったそうです。機能領域やアプリケーションモジュールごと（サンプル画像だと「ドキュメント編集機能」、「印刷 ＆ エクスポート機能」とかになっている）のテスト管理になっています。これがデフォルトじゃなくなったってことは、機能別管理はモダンなテスト管理じゃないってことか。
気になったのでベースラインサポートのプロジェクトもちょろっと試してみました。テストケースのコピーはどのプロジェクト種類でも簡単にできますが、Masterがあってそれをコピーして修正して終わったらMasterにマージして・・・といったGit風のテストケース管理ができるようです。これだと、マスタケースを育てやすそう。プロジェクトをまたいでテストケースコピーもできるので、思いついた使い方としては、
- マスタとなるテストケースはベースラインサポートプロジェクト。リグレッションテストなどでも使えそう。
- それ以外は通常のプロジェクトで管理。
とかどうですかね？ ベースラインは「Test Suites」らしいです。
話を戻します。基本情報を登録するだけで簡単にプロジェクトは完成します。さぁ、ここからが本番。TestRailはテストケース意外にも階層構造を持っています。上で作ったプロジェクトもその一つ。それ以外のものを見てみましょう。
今回は、旅行予約サイトを想定してテストケースを作ってみました。目立つ機能だけ抜粋してます。
- 施設ユーザは、ホテル情報や部屋情報を入力できる。
- 施設ユーザは、部屋の在庫や値段を管理ができる。
- 宿泊客は施設を探せます。
- 宿泊客は施設を予約できます。
大きく分けて、施設側と宿泊者側で機能が分かれ、それぞれは関係しています。施設の情報をいじったら、宿泊者にどう見えるか確認しなければならないのが、今回のテスト対象の特徴でもあります。
セクション
テストケースをグループ化するためには「セクション」を使います。セクションのサンプル名が「Ex: Save Dialog Tests, Contact Form or Performance Tests」なので、「どの機能や画面のテストか」をベースに名前をつけると良さそうです。
ここでは大きく「施設側のテスト」と「宿泊者側のテスト」に分けました。そして、それぞれの中に、サブセクションとして機能ごとに分類しています。こう考えるとテストって分類の技術いりますね。
テストケース
そして、言わずと知れたテストケース。TestRailの最小データ単位です。それぞれのセクション以下にケースを作ってみました。TestRailでは右側にエクスプローラー型のビューがあるので、とても見やすいです。
それぞれのテストケースの詳細はこんな感じ。テストの想定時間を入れておくと、あとで見積もりもしやすそうですね。あとは、表形式の入力も可能ですが、Markdownみたいな記法だったので、すごく入力がしやすいわけではなさそうです。
マイルストーン
複数のTest PlanやTest Runを、一つのマイルストーンにまとめることができます。マイルストーンのサンプル名が「Ex: Version 1.0 or Internal Beta 2」なので、バージョンといったリリース単位の何かが良さそうです。
テスト計画（Test Plan）
テスト計画には複数のテストランを含めることができます。テスト計画名のサンプルが「Ex: All supported browsers or Operating system/database combinations.」なので、「何を」テストするかみたいな感じがよさそう。
テストラン（Test Run）
テストの実行単位。複数のテストケースを含めることができます。テストラン単位でテスト結果（進捗など）がまとめられます。テストラン名のサンプルが「Ex: Test Run 2014-08-01, Build 240 or Version 3.0」なので、バージョンやビルド番号や実行開始日がよさそう。
機能説明のページを見ると、クロスデバイスやマルチデバイス、OS、ブラウザといった、何回も繰り返すコンビネーションテストを簡単に作ってくれますね。
- 施設紹介の入力テスト（Chrome）
- 施設紹介の入力テスト（IE）
- ・・・
環境ごとの設定ファイルの管理とかもできるみたいです。
また、テストランを作るときに「リグレッションテスト」といったテストの種類やテストの優先度を選べるので、「今回はこの観点でテストする」とかも可能。どちらかというとテストのスコープ調整はここでする感じ？
TestRailの階層構造
TestRailの階層構造をここでまとめてみるとこんな感じです。そこに具体的な名前をつけてみて、使い方をイメージしてみましょう。
- マイルストーン： Version 1.0.1
- テスト計画： 基本機能の全動作確認、クロスブラウザテスト
- テストラン： Test Run 6/4/2016、Test Run 6/10/2016
- セクション： 施設側の機能
- サブセクション: 基本情報の入力
- テストケース： 施設名を入力できる、施設の紹介文を入力できる
これを文章にしてみると・・・
Version 1.0.1では、基本機能の全動作確認、クロスブラウザテストをテストします。1回目はTest Run 6/4/2016、2回めはTest Run 6/10/2016を実施。実施内容は「施設側の機能」の「基本情報の入力」の「施設名を入力できる」と「施設の紹介文を入力できる」の2ケースです。
結構イメージしやすい作りですね。
ただ、テスト計画 ＝ テストのスコープのような構成なので、テスト計画を開くと、機能ごとにまとまったセクションが入っていそうなものですが、実際はテストラン（テストの実行単位）が入っています。このへんがわかりにくい。
上の画面を見るとわかると思いますが、テスト計画に「クロスブラウザテスト」と名前をつけてみました。例えば、その計画の中には「IEでのテスト」とか「Chromeでのテスト」とかが入っててほしいものですが、テストランが入っているので、その中身を確認するためにもうワンクリック必要です。
テスト計画はテストスコープというより、テスト実施報告書みたいな感じで使うのですかね。しかも、テストランを二つ作って、二つとも同じテストケースを選んでも、テストの重複を指摘してくれませんでした。このへんは人間の力でやるしかないのか。
テストの実施
テストを実施していくとリアルタイムで進捗が更新されます。時間の計測もぽちっとできますね。ツールの強みであるトラッキングも簡単そうです。
テストランの結果だけで、テスト実施報告書みたいになりますね。バグ発見時はトラッキングツールとの連携もできるので、シンプルで使いやすいツールのように感じます。なんか、ヘビーなJIRAとは違って、ライトなRedmineに似ている雰囲気。使い方に困るイメージはありませんでした。
まとめ
http://www.slideshare.net/oota_ken/taas4
やり方に限界が来たらツールを探すのはセオリー。探してみるといろいろありますが、テストの伝道師である太田さんが主要サービスをまとめてくださっていたので、それを参考にさせていただきました。今回はTestRailを試してみましたが、時間があればそれ以外のサービスも見てみます。
ちなみに。
昔、後輩のエンジニアが何人かTestRailを調べたときがあって、そのときの結論は全員が「Excelで十分」とか「俺たちならもっと良い管理ツール作れる」とか生意気なこと言っていました。お金を出してまで使うツールという感じではなかったみたいです。たしかに、僕も前職で一度導入したことがありますが、Excel以上の使い方ができずに使うのをやめたことがあります。
でも、個人的にはある程度の規模があるシステムのテストを管理するなら、悪くないツールのように思います。自動テストとのすみ分けまでここで見えたらもっといいですね。
それ以外の機能だと、みんな大好きレポーティングやメトリクス部分は今回調べなかったので、公式サイトの機能紹介ページを参考にどうぞ。英語だけどチュートリアル動画もありました。Excelからのインポートもできるみたいなので、使うなら移行も簡単そうですね。
TestRailは欧米型テスト管理ツールなので「従来の機能別の管理」とはちょっと違うみたいです。詳しくは「欧米のテスト管理ツールとCATにおける、要求の違いについて」が面白い。
旅と子育てとアジャイルコーチのブログ「世界」 