こんにちは。QAチームのmiyagiです。
QAで最近導入したTestRailというツールについて、導入の背景や、スプレッドシートからこのツールに乗り換えて変わったことについて書いていきたいと思います。
TestRailとは
TestRailは、主にテストケースの作成・更新やテストの進捗管理ができるテスト管理ツールです。
ツールの開発元はドイツのGurock社で、日本ではテクマトリックス株式会社が販売代理店となっており、同社から日本語でサポートも受けられます。
テスト管理ツールを導入した背景
テスト管理ツールを導入した理由は大きく分けて2点あります。
1点目はテストケースのデータベース化を実現するためです。具体的には以下の内容を行うためのツールが必要でした。
- テストケースのマスタを作る
- テストケースのマスタから実行するテストケースのセットを条件に合わせて抽出する
TestRailへの移行と同時にリスクベースドテストの仕組みを導入するため、テストケースへの優先度付けとテスト端末のTier付けを実施しており、この基準によってテストの網羅性を決定しています。
実行するテストケースの抽出を上記の条件で行うため、それができるテスト管理ツールを導入することとなりました。
2点目はスプレッドシート管理により発生している様々な問題を解決するためです。
これまでGunosyのQAチームでは、各プロダクトのリリース前のテストで使用するテストケースの管理は全てGoogleスプレッドシートで行なっていました。
スプレッドシートを利用したテストケースの作成・管理は、一覧性の良さやコピー&ペーストのしやすさ等の使いやすい面もありますが、テストケースが膨大になってきたことでデメリットも増えてきました。
スプレッドシート管理により発生した課題は以下のようなものが挙げられます。
- 複数ファイルに分かれるため過去のテストケースを一括して検索することができない
- テストケースの編集履歴の管理がしにくい
- 手動テストと自動テストの結果入力が煩雑になる
- 進捗やテスト結果入力の数式が壊れやすくメンテナンスが必要
スプレッドシートではできないテストケースのデータベース化、また、スプレッドシート管理による課題の解決を目的にTestRailを導入することとなりました。
TestRailを導入して変わったこと
TestRailを実際に使い始めてどのような変化があったのか、テストの工程別にまとめます。
テスト準備
テストケースのマスタから実行対象のケースのみ抽出できるようになった
Gunosyではプロダクトのリリース前に変更箇所に対してのエンハンステストと、既存機能に対しての回帰テストを実施しています。
リリースの内容やテスト端末によって実際に実行するテストケースは変わりますが、スプレッドシートでは実行するケースと実行しないケースが混在してしまい、テスト結果の視認性が良くありませんでした。
TestRailに移行したことで、テストケースのマスタからテスト端末毎に実行対象のケースだけを抽出してテストラン*1を作成することができるようになりました。
これによってリリースバージョン別にどの機能に対してテストを実施したのかが明瞭になり、テスト実行時や結果確認時の視認性が上がりました。
テスト実行
テストの種類毎・テスト端末毎の進捗が見やすくなった
リリース毎に実施するエンハンステストと回帰テストのテストケースは別々のテスト計画*2を作成して管理しています。
また、各プロダクトでiOS、Androidでそれぞれサポートしている複数のOSバージョンをテスト対象としています。
TestRailではテスト計画の下にテストランをテスト端末(OSバージョン)毎に作成しており、各テスト結果のステータス別の件数や未実行のケース数、全体の進捗状況を簡単に把握することができます。
スプレッドシートでは全体の進捗率の確認のみで、グラフの作成は行なっていませんでしたが、TestRailではグラフが自動で作成されて視覚的に一目で分かりやすくなりました。
テストの結果入力がしやすくなった
スプレッドシートではコピー&ペーストでテスト結果の一括入力はしやすいですが、テスト環境の数だけ列が増えてシートが横に伸びるため、画面サイズによってはスクロールが必要でした。
TestRailでは各テストケースにチェックボックスが存在し、複数ケースを選択することでテスト結果の一括入力ができます。複数環境でのテストはテストランが別々になるため結果を一括入力することはできませんが、ケースを複数選択しての結果入力がやりやすいため、テストラン毎の入力はさほど手間にはなりません。
セクション毎にケースを一括選択することもでき、機能のカテゴリ毎に結果を一括入力することも容易です。
Gunosyでは回帰テストの一部のテストケースを自動テストで実行しており、自動テストでは複数のケースを機能のカテゴリ毎にまとめて実行しているため、機能毎に結果を一括で入力できるのは便利です。
テストケースの管理
検索がしやすくなった
過去に実施した特定のテスト結果を確認したい時、これまではリリースバージョン毎にスプレッドシートが別ファイルになっていたため、まずは探したいテストケースが含まれるファイルを探し出すという作業が必要でした。
TestRailに移行したことでテストケース全体がデータベースになり、過去の全てのテストケースからキーワード検索することができるようになりました。
テストケースとテスト結果の両方が検索結果に表示されるため、特定のテストケースを編集したい場合や結果を確認したい場合にすぐ見つけることができ、利便性が上がりました。
編集履歴がわかりやすくなった
スプレッドシートにも編集履歴は残りますが、ある特定のテストケースがどのように編集されたのか遡って探し出すのは困難でした。追加・変更の履歴を手動で記録するのも煩雑になります。
TestRailでは特に何もすることなく、テストケースに対していつ誰がどのような変更を行なったかが記録されるため、後から必要に応じてテストケースの詳細画面で変更履歴を確認することができます。
まとめ
スプレッドシートからTestRailに移行して変わったところについての話でした。
TestRailの導入によってテストケースの管理方法が全く変わったことで手間取ることもありましたが、操作にも慣れたことで現在はスプレッドシートからの移行によるメリットの大きさを感じます。
今後は自動テストとの連携やレポート機能なども活用できるよう取り組んでいきたいと考えています。
