テスト管理ツールの導入を検討することになったきっかけは？

テクマトリックス：
まず初めに、田口様と宮城様が所属している、QAチームの業務内容について、教えていただけますか？

QAエンジニア 宮城様：
株式会社Gunosyは、主に「グノシー」、「ニュースパス」、「auサービスToday」の３つのアプリの開発・運営を行っています。
QAチームでは、各プロダクトのシステムテストを実施しています。テスト対象は、3つのアプリと社内システムです。アプリをリリースするたびに、機能の追加や既存機能の改善のために修正が行われますので、変更箇所に対するエンハンステストと、変更のない既存機能に対する回帰テストを行います。エンハンステストは手動テストで実施しますが、回帰テストの一部はツールを使って自動化しています。

テクマトリックス：
テスト管理ツールの導入を検討したきっかけは何ですか？

QAチーム マネージャー 田口様：
テストケースを管理する上では、表計算ソフトは限界があります。データベースをバックグラウンドにした最新のツールを使うことで、テストの効率化と、それに伴うソフトウェアの品質向上が期待できると考えました。

テクマトリックス：
Gunosy様では、過去にテスト管理ツールの導入を検討されたこともあるそうですね。

QAチーム マネージャー 田口様：
はい。検討したのは数年前ですが、ツールの調査はしたものの、企画倒れとなり、導入には至りませんでした。企画倒れになった原因は、ツール導入の目的を明確にイメージできていなかったことと、収集したツールの情報にばらつきがあり、十分な比較検討ができなかったことにあります。
そこで今回は、自力で調査するのではなく、RFP形式を採用して、ツールベンダー各社から実現可能なソリューションを提案してもらう方法で検討することにしました。

テスト管理ツールを導入する前のテスト管理はどうしていた？課題は？

テクマトリックス：
各ツールベンダーからの提案を元に、テスト管理ツールの導入を検討したということですが、テスト管理ツールを導入する前のテスト管理はどうしていましたか？

QAエンジニア 宮城様：
Googleスプレッドシートを使用して、テストケースの管理と進捗状況の管理を行っていました。
私たちは、主にスマートフォンで動作するアプリを提供しています。動作確認は各アプリで対応するOSごとに実施する必要があるため、効率的にテストを行う仕組みを作っていました。具体的には、機能一覧シートとテストケース一覧シートを作成して、機能一覧シートでテスト対象の機能にチェックを入れると、その機能のテストケースのみがテストケース一覧のシートで実施対象として表示され、それ以外のテストケースは結果入力欄がグレーアウトするような設定で運用していました。
また、進捗状況の管理は、機能ごとのテストケース数と進捗率、OK/NGの件数を表示する集計シートを作成して行っていました。

テクマトリックス：
テスト対象のテストケース作成や、進捗管理に関して工夫されていたようですが、Googleスプレッドシートを使用したテスト管理に課題はありましたか？

QAエンジニア 宮城様：
それぞれ、以下の課題がありました。
＜テストケースの管理＞

• フォルダやファイルが分散しているため、テストケースを探すのが難しい。
• 実行対象と対象外のテストケースがシート内で混在しているため、見分けにくい。
• 手動テストと自動テストでは得られるテスト結果の形式が異なるため、結果の入力が煩雑になる。

＜進捗管理＞

• データの整理やグラフの調整など、直感的に理解できるグラフを作るには手間がかかる。
• データの変更や数式の複雑さで、集計の数式が壊れやすい.

このような課題を解決するために、Googleスプレッドシートからテスト管理ツールへの移行を検討し始めました。

テスト管理ツールを導入することで、実現したかったことは？

テクマトリックス：
テスト管理ツールを導入することで、具体的にどのようなことを実現したかったのでしょうか？

QAエンジニア 宮城様：
テストケースをデータベース化し、条件を指定して必要なテストケースを抽出できるようにしたいと考えました。指定する条件は、機能や優先度、手動テスト/自動テストなどです。
また優先度の条件には、リスクベースドテストの手法を導入することを検討していました。テスト対象の機能に対して、リリース後に不具合が発生した場合の影響度と、その機能のユーザーの使用頻度の2つを定義し、それに基づいて、テストケースを重みづけするという手法を採用することで、リスクの高いテストケースを網羅的に抽出したいと考えていました。

テクマトリックス：
データベースから条件を指定してテストケースを抽出できるようになると、限られた時間の中で本当に必要なテストを実施することができそうですね。テスト管理ツールを導入した後、どのように運用しようと考えていましたか？

QAエンジニア 宮城様：
各アプリのテストケースの更新情報(テストケースの追加・変更・削除)は、テストケースのマスターに集約します。テストを実行する場合は、テストケースのマスターから条件を指定して、実行するテストケースのセットを抽出します。自動テストのテストケースも、同様にテストケースのマスターに集約して管理することを計画していました。

RFPを用いたツール選定の流れや、評価の項目は？

テクマトリックス：
テスト管理ツールに対する期待値などをお伺いすることができました。インタビュー前半で田口様から、ツール選定にRFP形式を採用されたと伺いましたが、どのようにツール選定をされたか詳しく教えていただけますか？

QAエンジニア 宮城様：
RFPとは、Request for Proposalの略で、日本語では「提案依頼書」と訳されます。まず当社でテスト管理ツールに対する要件を記載した提案依頼書を作成しました。そして、ツールベンター各社で提案依頼書に基づいた提案書を作成して、プレゼンテーションを実施していただきました。
RFP形式を採用することで、メンバーによる偏った情報収集を解消して、ベンダーから当社の要件に合ったプレゼンテーションを受け、最適なツールを選定できると期待していました。

テクマトリックス：
RFPを用いてツールを選ぶ流れを教えてください。

QAエンジニア 宮城様：
まず参加企業を絞りました。「日本語UIに対応」、「日本語でサポートを受けられる」という条件を満たす企業として、RFPに参加いただく4社を選定しました。

テクマトリックス：
選定した４社のプレゼンテーションは、どのように評価しましたか？

QAエンジニア 宮城様：
採点方式で評価を行いました。各要件の重みを示すWeightと、要件の満足度であるScoreを掛け合わせたスコアがツールの評価になります。

• Weight：各要件の重みづけを事前に設定する。必須の要件は2、必須ではない要件は1。
• Score：各要件の満足度を4段階で評価する。

4つのツールに対して、QAメンバー全員で評価を行い、比較しました。

テクマトリックス：
要件の項目を教えてください。

QAエンジニア 宮城様：
項目は、約50個あります。大項目は以下の７個です。たとえば、大項目「システム設定」には、シングルサインオンによる暗号化通信やサポート体制などの、社内で求められるセキュリティ要件が含まれています。
テスト管理ツールに対する要件の大項目：

• システム設定
• テストケース作成、管理
• テスト実行
• 実行結果の確認
• バグ管理システムとの連携
• 自動テストツールとの連携
• 操作性

テクマトリックス：
要件の項目以外に、提案書で特に注目すべきポイントはありましたか？

QAチーム マネージャー 田口様：
単なる機能紹介だけではなく、当社から提示したRFPに基づいて実現方法を説明していただけていることが最低限の条件でした。その基本的な条件を満たした後、具体的な要件の項目を評価しました。

テクマトリックス：
日本語でサポートを受けられる４社の中から、Gunosy様の要望を実現できるソリューションをしっかり提案した上で、要件に対するスコアが高いツールとして、TestRailが選ばれたということですね。
RFPを使ったツール選定をしてみて、どうでしたか？

QAエンジニア 宮城様：
RFPを使うと、自分で調べるよりも正確にかつ、効率的にツールを選定できます。実現したいことを提案者側に伝えることで、提案者も具体的なイメージを描きやすくなると感じました。

テクマトリックス：
RFPを使ったツール選定は、これからツールを選定する方に役立つ情報だと思います。教えていただき、ありがとうございます。

最終的にTestRailを選択した理由は？

テクマトリックス：
他社ツールと比較して、TestRailを最終的に選んだ理由は何ですか？

QAエンジニア 宮城様：
TestRailのコンセプトであるテストケースの資産化は、当社の目的であるテストケースのデータベース化と合致していました。TestRailを利用することで、テストケースやテスト結果を簡単に検索でき、過去のテストケースを再利用しやすくなり、個別のテストケースの変更履歴や結果を確認しやすくなります。
他社の表計算ソフトライクのツールでも想定していた運用はできますが、多少の工夫が必要でした。スプレッドシートを使っていたため表計算形式のツールを導入するハードルは低かったのですが、移行するメリットが少ないと考えました。



テクマトリックス：
TestRailは、テストケースやテスト結果などのテストに関する記録をWeb上で一元管理しますので、欲しい情報にすぐアクセスできるところが、ポイントだったんですね。

QAエンジニア 宮城様：
RFPで記載した項目を網羅したプレゼンテーションで、当社の要求を実現できることを明確に示していただいたことも、決め手になりました。

テクマトリックス：
TestRailを採用していただき、ありがとうございます。
GoogleスプレッドシートからTestRailへ移行する際に、既存のテストケースをTestRailへインポートする必要があったと思います。どのような手順で行いましたか？

QAエンジニア 宮城様：
GoogleスプレッドシートからTestRailへ移行するには、以下のステップを踏みました。
まず、TestRailで、テスト対象のアプリごとに「プロジェクト」というリポジトリを作成し、その中に「テストスイート」というテストケースをまとめたフォルダを作成しました。
次に、TestRailのフォーマットに合うように、既存のテストケースを管理しているスプレッドシートを整備しました。TestRailではテストケースの階層構造を、「セクション」を使って表現することができます。また、テストケースをTestRailに一覧表示するために、テストケースごとに「タイトル」を付ける必要もありました。このタイミングで、テストケースの内容の見直しも行いましたので、この作業が最も時間がかかりました。
最後に、整備したスプレッドシートをCSVに変換して、TestRailへインポートしました。通常業務の合間に少しずつ進めて、3,500件のテストケースを移行しました。

テクマトリックス：
移行作業にはどれくらいの時間がかかりましたか？

QAエンジニア 宮城様：
スプレットシートで管理していたテスト情報が整理できていれば、CSV変換とインポートはすぐに完了することができたと思います。しかし、このタイミングで既存のテストケースの見直しも行いましたので、時間がかかりました。
通常のテスト業務と並行して移行作業を行う必要もあったため、すべてのプロダクトのテストケースを移行するのに4～5カ月かかりました。

TestRailの現在の利用状況は？

テクマトリックス：
TestRailの現在の利用状況はいかがですか？

QAエンジニア 宮城様：
QAチームが担当するすべてのプロジェクトのテストケースを、TestRailに移行して利用しています。移行したテストケースの件数は、「グノシー」、「ニュースパス」、「auサービスToday」の3つのアプリに対して、合計3,500件です。
アプリをリリースする前にTestRailを利用してテストを行っています。これまでに数十回以上のテストを実施して、アプリをリリースしました。今のところ問題はなく、TestRailを活用して効率的にテストを進めることができています。

QAチーム マネージャー 田口様：
私たちは、社内システムのテストもしていますが、社内システムのテストにもTestRailを使用しています。前述のアプリに比べて、頻繁な更新はありませんが、数カ月に1回の新機能の追加時に、TestRailを利用してテストを行っています。

テクマトリックス：
スプレッドシートのテスト管理で抱えていた課題は、TestRailを導入したことで解決できましたか？

QAエンジニア 宮城様：
はい、具体的には以下の改善効果が得られました。

• 複数のファイルで管理されていたテストケースをデータベース化することで、すべてのケースを検索できるようになった。
• テスターがテスト結果を入れるだけで、リアルタイムにテスト進捗のグラフが表示されるようになった。
• テスト結果を、手動テストと自動テストで「テストラン」ごとに分けて入力することで、それぞれのテスト結果が分かりやすくなった。
• テスト結果入力時に、テスト対象の機能カテゴリで一括選択できるようになったことで、結果入力がしやすくなった。

テクマトリックス：
課題が解決できたとお聞きし、嬉しく思います。自動テストツールとの連携はしていますか？

QAエンジニア 宮城様：
現在、テスト結果を入力する際は、「テスト計画」の下の階層に「テストラン」を作り、2階層にしています。「テストラン」は、OSのバージョンや自動テスト/手動テストの種類ごとに作成して運用中です。自動テストの結果入力は手動で行っている状態ですが、今後、自動連携する予定です。TestRailにはAPIが実装されているということだったので、自動連携はさらなる作業効率化の一手としてチャレンジしたいと考えています。

テクマトリックス：
お伺いしたような構成で管理することで、「テスト計画」で全体的な進捗率を把握し、自動テストと手動テストの進捗率も個別に確認できますね。
評価の項目で挙がっていた機能とは別に、実際に使ってみて、一押しの機能や使い方があれば、ぜひ教えていただきたいです。

QAエンジニア 宮城様：
テスト実行時のUIが気に入っています。左側にテストケースの一覧、右側に詳細を表示する形式が、非常に使いやすいです。細かいですが、結果を入力すると次のケースに自動で進む点も便利です。


テクマトリックス：
UIのデザインを気に入っていただけて嬉しいです。

QAエンジニア 宮城様：
テストの進捗状況のグラフも見やすいです。OSバージョンごとの進捗状況も、全体の進捗状況と別に確認できるので、活用しています。

TestRailに期待することは？

テクマトリックス：
TestRailは常に機能拡張を行っています。今後、TestRailに期待することはありますか？

QAエンジニア 宮城様：
テストケースを選択して実行するテストケースのセットを作る際に、設定した条件を保存できるようにしてほしいです。優先度の設定など、ある程度決まった条件を設定する場面が多いので、時間を節約できると思います。

テクマトリックス：
TestRailは常に機能拡張を行っています。今後、TestRailに期待することはありますか？

QAエンジニア 宮城様：
テストケースのレビュー時に、コメントを残せる機能があると便利だと思います。また、テストケース以外のテスト設計ドキュメントやテスト計画ドキュメントも、TestRail上で一緒に管理できるようにすると、より便利になると思います。

テクマトリックス：
テストケースに関連する情報をより多く残せれば、テストの実施がしやすくなるということですね。テストケースのレビューにつきましては、TestRail Enterpriseの次のバージョンで、テストケースの承認機能が追加されます。承認する際に、コメントを残したり、専用のステータスを指定したりできるようになります。


QAチーム マネージャー 田口様：
IEEE829の規格では、テストプランやテストデザインなどの成果物をテストウェアと呼びます。TestRailにはテストウェアの管理機能がないため、テストプランはConfluenceやクラウドストレージに保存する必要があります。テストケース、テスト結果の管理機能を充実させるだけでなく、テストウェアもすべてTestRail上で管理できるようになるといいなと思います。

テクマトリックス：
貴重なご意見ありがとうございます。このようなご要望は、弊社でまとめて開発元に伝え、機能拡張に向けて取り組みます。

TestRail利用の将来的な展望は？

テクマトリックス：
TestRailを活用いただけているようですが、TestRail利用に関してさらなる展望などはお持ちですか？

QAエンジニア 宮城様：
現在、自動テストの結果入力は手動で行っています。今後は、自動テストツールとAPI連携をして、自動で結果入力するようにしたいと考えています。

QAチーム マネージャー 田口様：
将来的には、生成型AIですべてのテストケースを自動生成できるようになるといいですね。弊社でも、研究部門でAIの研究をしています。

テクマトリックス：
生成型AIを活用できれば、テストがより効率化しそうですね。貴社の研究成果を参考にさせていただければ幸いです。
現在、QAチームでTestRailを利用していますが、今後、開発者の方にもTestRailを利用いただくなど、利用範囲が広がる可能性はありますでしょうか？

QAチーム マネージャー 田口様：
QAチームで人が増える可能性もあるかもしれないですね。それ以外に、開発者やプロジェクトマネージャーなど、他部署からも利用したいという要望がありますが、コストに見合うかどうかは検討が必要です。そのような観点でも、外部連携を強化して、テストプランやテストデザインなどの情報を、TestRailのアカウントから一括で簡単に確認できるようにすれば、より多くの人に利用してもらえると思います。

テクマトリックス：
別のデータベースやシステムに生データがあっても、TestRailの連携機能がより強化され、外部データを確認できるようになると、利用範囲が広がりそうですね。ご意見いただき、ありがとうございます。

QAチーム マネージャー 田口様：
さまざまなツールとの連携性を検討していただけると嬉しいです。

テクマトリックス：
本日は貴重なお時間をいただき、誠にありがとうございました。引き続き、TestRailをよろしくお願い申し上げます。

• 掲載日：2023年10月
• 資料記載の担当部署は、取材時の組織名です。