インタビュー内容

テスト管理ツール検討のきっかけと目的は？ テスト管理ツールに求める条件と、TestRailを選んだ決め手は？ セーフィー様のプロジェクト数と開発スタイルは？ TestRail導入時の周囲の反応は？上司の方やテスターの方の声は？ テストデータの移行にかかった工数は？ 移行する際に苦労した点は？ TestRailを導入した効果は？実際に工数削減できた？ 不具合管理ツールとの連携やレポート機能の活用状況は？ 今後の展望は？

テスト管理ツール検討のきっかけと目的は？

導入きっかけ：複数プロダクトの進捗管理の手間 課題：スプレッドシートの視認性・再利用性 目的：効率的で視覚的に整理しやすいツールへの需要増

──テスト管理ツールを導入しようと考えたきっかけを教えていただけますか？

小山様：私自身、複数のプロダクトを担当することが多く、効率的にテストの進捗確認をする必要があったからです。
以前は、Googleスプレッドシートを使用してテストの進捗状況や結果を管理し、定期リリースに向けてテストを実施していました。しかし、スプレッドシートを使って進捗確認をすると、複数の担当者によるテストの実行結果を手動で集計しなければならず、さらに詳細な結果を確認するためには個別に開く必要があるため、すごく手間がかかってしまう状況でした。
そこで、効率的に管理方法を探していた中で、テスト管理ツールの存在を知り、TestRailに興味を持ちました。

山谷様：スプレッドシートでのテスト管理には、進捗確認の煩雑さに加えて視認性の悪さという課題もあります。
例えば、長いテストケースはセルに収まりきらず、モニターサイズによってはレイアウトが崩れ、スクロールしてもすべての情報を把握するのが難しくなってしまいます。また、テストの実行結果にメモを残す場合も、セルの表示形式に制約があるため、見やすく整理しにくいという問題もあります。
そのため、レイアウトの崩れなどを気にすることなく必要な情報を気軽に登録でき、かつ視覚的にテスト情報を整理できるツールを探していました。


山谷様：既存のテスト資産の再利用にも課題を感じていたので、ツールを導入して、よりスムーズにテスト資産を再利用できればと期待もしていました。

テスト管理ツールに求める条件と、TestRailを選んだ決め手は？

条件：直感的なUI操作性、スプレッドシートを超えるテスト管理効果 決め手：分かりやすいUI、全員の利用負荷の低さ、柔軟性とテスト管理への適合性

──TestRailを導入する前に、他のテスト管理ツールと比較されましたか？

小山様：最初は他のテスト管理ツールを試してみたのですが、UI操作が難しく、上手く使えませんでした。その後、TestRailにトライアル期間があることを知り試してみたところ、自然な操作性で、直感的に使えると感じました。

山谷様：正直なところ、スプレッドシートは非常に万能で、無理をすればいかようにもカスタマイズして利用できるという汎用性を持っていると思います。それを差し引いても、テスト管理という点においてより効果的なツールであれば導入したいと考えていました。

──操作性が良いだけでなく、スプレッドシートと比較してテスト管理において導入効果がしっかり出るということが条件だったということですね。最終的にTestRailを導入していただいたのですが、決め手は何だったのでしょうか？

小山様：一番は、使いやすいUIです。テストを実施する際にも分かりやすく、ダッシュボードや集計ページ、テストの割当て機能、TODOリストなど、マニュアルを読まなくても直感的に操作できるように設計されている点に惹かれました。

山谷様：TestRailは、チーム全員の利用負荷がスプレッドシートより上がらないという必須条件をクリアしていました。他のテスト管理ツールと比較しても、群を抜いていました。それに加えて、TestRailはスプレッドシートよりも柔軟性があり、テスト管理に適していると判断し、導入を決めました。

──UIが分かりやすく、テスターの方が直感的に利用できるところは、TestRailの特長の1つです。その結果、慣れ親しんだスプレットシートからの移行で気になることが多い、ツールの学習コストを抑えられるという点が、セーフィー様のニーズにマッチしたのかなと思います。

セーフィー様のプロジェクト数と開発スタイルは？

プロジェクト数：基盤プロダクト常時6～7個、年間約10の横断的プロジェクト 開発スタイル：ウォーターフォールに近いが、一部アジャイルの要素も取り入れ、月数回リリース

──具体的なTestRailのご利用状況をイメージするために、セーフィー様のプロジェクトや開発スタイルについて教えていただきたく思います。御社では、どのくらいのプロジェクトがあるのでしょうか？

山谷様：基盤のプロダクトは常に6 ～ 7個あり、さらに年間でおおよそ10の横断的なプロジェクトが走っています。基盤プロダクトは定期的にリリースしていて、それに伴ってプロジェクトのリリースも行われるようなイメージです。

──どれくらいのリリース頻度なのでしょうか？月に数回のリリースがあるということですか？

山谷様：基盤プロダクトの定期リリースは必ずありますね。さらに、アプリやデバイスのファームウェアのリリースも含めると、毎月数回のリリースがあります。

──月数回のリリースとなると、開発スタイルについても気になります。これだけのリリース頻度ということは、完全にアジャイル開発なのでしょうか？

山谷様：リリースは頻繁に行っていますが、開発体制のベースはウォーターフォールに近い形です。一部のプロセスでは、アジャイルのような動きも取り入れています。

──セーフィー様のリリースのスピード感を考えると、ウォーターフォールでは不可能に近いのかなと思いました。良いとこ取りアジャイルのような感じなのですね。

山谷様：基本的には 、１ヵ月や ３ヵ月の短いスパンで開発を行い、エンハンスの量を絞ってリリースしています。 1 年スパンの開発もありますが、その場合は、1か月をかけて QAを行うような感じです。テスト対象を絞るような活動も重要ですので、TestRailを使用することで過去の結果を含めて資産化できるという点は非常に重要なポイントになると考えています。

小山様：アジャイルに近い形で進める場合は、１週間や2 週間 の短い期間のスプリントで開発を進めながら、同時にQA も行っています。スプリントの期間が短いと、どうしてもTestRailへのデータ投入が間に合わないような場合があるので、TestRail移行過渡期の今は、一部ではスプレッドシートを 併用して、スプリント内で作業を完了させることもあります。

TestRail導入時の周囲の反応は？上司の方やテスターの方の声は？

テスト設計者：TestRailでの効率化に期待感が高い 少人数プロジェクト担当者：スプレッドシートでも満足 上司：工数削減とテスト準備の効率化に対して良い反応 テスター：スプレッドシートと同等の使いやすさだが、大量テストケースの管理で課題感じる

──導入時、周囲の方の反応はどうでしたか？慣れ親しんだツールからの移行はどの会社様も苦労されているという話を聞きます。

小山様：テスト設計者の期待感が高かったです。特に、複数プロダクトを担当している担当者は、TestRailを使うとテスト管理を効率化できるという点に強い関心を持っていました。一方で、担当しているプロダクトのリリース時期が重なっていなかったり、テスターが少ないプロジェクトを管理したりしている場合は、どちらでも構わないという意見もありました。

山谷様：少人数のプロジェクトを専任で担当している場合は、統合管理の意味合いが薄れてしまうという話ですね。
例えば、テスト作成者とテスト実施者が同じであり、テストケースを作りながらテストを実施するような場合や、エンハンスが少ない場合には、スプレッドシートでも十分なので、TestRailの価値が出にくくなってしまうと感じます。複数のプロジェクトを担当する場合や、多数のメンバーが関わるプロジェクトにおいて価値を感じやすいと思います。

──プロジェクトの性質によって、実際の担当者の方の意見が変わるということですね。上司の方からの反応はどうでしたか？

小山様：テスト管理の工数削減や、再利用によるテスト準備工数の削減に対して、良い反応がありました。費用が発生するものの、QCDグループが将来的にも拡大していくということと、現場の負担が軽減されるという理由で、承認をいただきました。

──御社内でTestRailの利用範囲を広げていく中で、実際にTestRailを使い始めた方々の反応はいかがでしょうか。使ってみて、何か課題を感じることはありますか？

山谷様：テスターの方からは、使い慣れたスプレッドシートと同様の使いやすさで、違和感なく操作できるというポジティブな意見でした。
一方で、テストの作成や修正は、工夫が必要な場面がありました。小規模な場合はTestRail上で問題なく作業できるのですが、大量のテストケースを作成する際には、まずはスプレッドシートでテストケースを作成し、それをTestRailにインポートするという作業が発生しました。一時的に、TestRailとスプレッドシートで二重管理になってしまったので、大量のテストケースを作成するシーンにおいては、UIの仕組みに課題を感じました。

──大量のテストケースの追加や上書きについては、弊社も何かいい方法がないかと考えており、TestRailの開発元と相談しています。TestRailを利用していただいている他の会社様でも、大量のテストケースを追加したり、修正したりする際は、スプレッドシートやエクセル上でテストケースを整理して、TestRailにインポートすることが多いです。貴重なご意見、ありがとうございます。

テストデータの移行にかかった工数は？

移行工数：約3,700件のテストケースを約60人日（約160営業日）で移行 評価：テスト手順の見直しが含まれ、作業に対する納得感があり、ネガティブな意見はなし 効率化：作業の慣れとノウハウ蓄積により、後期のプロジェクトでは工数削減が実現

──スプレッドシートからTestRailへの移行はどのように進めましたか？

小山様：スプレッドシートで作成したテストケースを、TestRailのフォーマットに合わせて調整して、TestRailにインポートしました。ちょうど良い機会だったので、同時にリグレッションテストの見直しも行いました。

──他のお客様においても、スプレッドシートからの移行時に、テストケースの整理やリグレッションテストの見直しを行いながら、テストケースをTestRailに投入するというアプローチを取られている方は多いですね。セーフィー様全体では、どのくらいの時間がかかりましたか？

小山様：すべてのプロジェクトを合わせると、約3,700件のテストケースを約60人日かけて移行しました。営業日数では約160日です。
テストの見直しも同時に行っていましたので、その時間も含まれています。もともとテストの項目数が多いプロダクトは、テストケース自体の見直しにも時間がかかってしまいました。

──移行に約60人日かかったということですが、御社内では、この移行にかかった人日が予想よりも多いのか、予想通りの範囲内なのか、どのように評価されていますか？

山谷様：移行にかかった工数について、特にネガティブな意見は出ていませんね。実際に作業を行った際も、メンバーは協力的で、快く取り組んでくれました。単にTestRailへの移行だけではなく、テスト手順の見直しにもつながったという納得感もあるかと思います。
例えば、Safie Manager（エンタープライズにも対応したSafieのカメラ用統合管理ツール）のテストケースには、高度な内容や、初めて見る人にとって理解が難しい内容が含まれていたため、手直しを行いました。
テスト手順の手直しさえできてしまえば、TestRailへの移行は簡単な作業だったので、TestRailへのインポート作業自体には手間がかからないという点もよかったかもしれません。

──さまざまなプロジェクトでTestRailを利用していただいていますが、プロジェクトによって移行にかかった工数は異なりますか？

小山様：作業自体は単純ですので、徐々に慣れてきてノウハウも貯まり、効率的に移行作業ができるようになったので、後に取り組んだプロジェクトは工数が減りました。例えば、従来のテストケースにTestRail上のセクションやタイトルなどの項目を追加した移行用のフォーマットを作成し、転記作業をしやすくしました。

──今後はテストケースの移行にかかる工数を圧縮できそうですね。

小山様：工数はかなり少なくなると思います。最後にデバイスのテストケースの移行を行いましたが、私が担当していて、元々は138項目あったものを1人日の1営業日で完了しました。だいぶ慣れてきたと感じています。

移行する際に苦労した点は？

苦労点：TestRailでのテストケースのナンバリングとステップ数の表現、スプレッドシートからの変換方法 解決策：大項目をセクション、中項目をサブセクションとし、「＞」でセル結合して変換 タイトル付け：セクションごとのタイトル選びに苦労 作業量増加：TestRailフォーマットへの慣れが必要だが、分かりやすいテストケース作成のため問題なし

──移行で苦労した場面があれば、教えてください。

山谷様：振り返ってみると、TestRail上でテストケースを大中小項目ごとにナンバリングして、ステップ数を正確に表現する方法を考えた際に、どうしたらよいか悩みました。最終的には、大項目をセクション*とし、中項目をサブセクション*として、ステップ数を考慮したテストを作成する方法で解決しました。
　*TestRailでは、セクションおよびセブセクションでテストケースをまとめます。


──大中小項目のテストケースには、この方法が使えそうですね。多くの会社で大中小項目を使っていて、私がこれまで見てきたテストケースもほとんどそうでした。

山谷様：スプレッドシートからTestRailのフォーマットへ簡単に変換したい場合は、すでに作成している大項目と中項目のセルの間に「＞」を入れて、セルの文字列を結合すれば 、TestRailのセクションとサブセクションが作れます。
他のチームにテストケースの作成をお願いする際は、大中小項目を使って作成してもらい、最後にこちらでセルを結合することで、セクションの概念を説明する手間を省くことができます。 テストケースの作成や整理する時間が限られている場合や、スプレッドシートからTestRailへ一括で変換する際に有効な方法だと思います。

──リアルな使い方が聞けて参考になります。テストケースの移行のコツですね。他にも苦労したところはありますか？

山谷様：タイトルの付け方は人によって異なることがあるので、苦労しました。セクション、サブセクション、タイトルをまとめて見ると意味が理解できるのですが、個々で見る場合はタイトルの選び方にも注意しないと、分かりにくくなってしまいます。

──細かな修正もあることを考慮すると、作業量が負担に感じることもありそうですね。

山谷様：テストケースは本来分かりやすく書く必要があるので、作業量は増えましたが私自身はそれを問題視はしていません。ただ、TestRailのフォーマットに慣れる必要がありますね。

TestRailを導入した効果は？実際に工数削減できた？

工数削減：具体的には、定期リリース時に「10分～20分×テスト期間の営業日」の削減を実現 進捗管理の容易化：ダッシュボードを使って進捗や成果物の確認が一目でできるようになり、日々の作業がスムーズに テストケースの可視化：必要なテストケースを簡単に選択し、見やすく表示できる 集計誤差の解消：スプレッドシート特有の集計誤差や数式壊れの問題が解消 テストケースの資産化：再利用や過去の結果参照がスムーズに行えるようになり、ルーティン作業から解放される

──TestRailを導入することで、期待していたメリットを得ることができましたか？

小山様：テスト管理の工数削減を期待していましたが、実際にそのメリットを実感しています。複数のメンバーが協力してテストを実施するプロジェクトが多いのですが、TestRailのおかげで、進捗や成果物の確認が楽になりました。

──具体的に、どのような場面でメリットを感じますか？

小山様：以前は、複数のテスト担当者の進捗を把握するために、昼と夕方の毎日2回、個々のスプレッドシートを開いて、手作業で集計していました。TestRailでは進捗がダッシュボードに表示されるので、一目で確認できます。複数のプロダクトを担当していても、該当するテストを選択するだけで簡単に確認できるため、日々の作業がとてもスムーズになりました。

山谷様：未実施/パス/ブロック/リテスト/失敗といったテストのステータスを、TestRailでは俯瞰的に確認できます。個別にスプレッドシートを開いて該当部分を探す必要がなくなりました。


──スプレッドシートでも工夫して進捗グラフなどを作成することは可能ですが、TestRailのようなウェブアプリを使用すると、リアルタイムに進捗状況を確認できます。実際に、どのくらいの工数削減に繋がったのでしょうか？

小山様：プロダクトにより大小はありますが、1つのプロジェクトの定期リリース時に、「10分～20分×テスト期間の営業日」の削減ができていると思います。

──複数のプロダクトを担当されていると思いますので、かなりの工数が削減されていることになりますね。実際に使用してみて、TestRailを使う方が有利だと感じていただけた点はありますか。

山谷様：スプレッドシートでのテスト作業では、スクロールしてもテストケースが続き、特に複数端末でのテストでは表示が横にも広がっていきます。個人の感覚ではありますが辛いと感じることがありました。
今はTestRail上で、必要なテストケースがクリックするだけで見やすく表示されるようになり、とても快適に作業ができます。

小山様：スプレッドシートを使っているときは、なぜか集計が１項目だけ合わず原因を考える必要があったり、同時に編集する際に気を使ったり、修正時に数式が壊れてしまったりすることがありました。その問題がなくなったことにも恩恵を感じています。工数の削減にもつながっていると考えています。

──「スプレッドシートでありがちなストレス」から解放されたというところは、大きなメリットですね。

小山様：TestRailは、テストケースの資産化の観点でも優れています。テストケースがマスターで管理されているので、再利用や過去の結果の参照がスムーズに行えます。
スプレッドシートでは、テストケースを再利用する際にシートの複製やセルの削除・追加、計算式の修正などの作業が必要でしたが、その作業が不要になり、嫌なルーティンワークから解放されました。



──例えば、条件を指定して全数テストを繰り返すこともあるのでしょうか？

小山様：プロダクトによりますが、リグレッションテストでは、すべてのテストケースを含むマスターテストケースを作成し、端末ごとに優先度に基づいて必要なテストケースを選んで実施しています。ハードウェアの仕様によって実施すべき項目をピックアップできるのは、すごく恩恵があります。

──TestRailを導入することで、想定通りにテスト工数を削減して、ストレスフルな細かな作業も減らすことができているということをお伺いできて、とても嬉しいです。

小山様：工数が削減されたので、以前は十分な時間を割くことが難しかった他の案件に取り組む余裕もできました。

不具合管理ツールとの連携やレポート機能の活用状況は？

TestRailとBacklogを連携し、TestRail上でBacklogのチケットが確認できる TestRailのレポート機能をテスト終了時に活用、プロジェクトごとの要求差によりレポート活用は改善余地あり レポートの新機能である信頼度曲線の出力を将来的に活用したい

──TestRailと不具合管理ツールの連携はしていますか？

小山様：不具合管理ツールはBacklogを使っていますが、TestRail上でテスト結果を入力する際にBacklogのキーを「欠陥」に入力することで、TestRailのテストケース上でチケットの詳細内容を確認できるようにしています。


小山様：TestRail上からBTS側にチケットを発行する機能も把握していますので、今後使っていこうと思っています。

──レポート機能は活用されていますか？

小山様：標準のテンプレートを使ってクリックのみで作成できるレポートを活用して、テスト終了時に提出しています。ただ、プロジェクトごとに求められる内容は異なるため、上手く活用できている部分と、できていない部分がありますね。
最近のTestRailのバージョンアップで、TestRailとBTSの連携がされていれば信頼度曲線を出力できるようになったので、将来的にプロダクトが成熟した際に活用できるのではないかと考えています。

今後の展望は？

TestRailを通じたテスト管理の一元化と効率化 未活用機能の積極的活用

──最後に、御社のTestRailの活用に関する展望や課題をお聞きしたいです。今後、さらに進めたいことや、取り組みたいことなどはありますか？

山谷様：まずは、各プロジェクトのテスト管理を平準化したいと思っています。バグの蓄積も含め、テスト情報をTestRailで管理したいという考えがあります。
今は、プロジェクトごとにマスターテストケースの活用度が異なったり、一部のエンハンステストがスプレッドシートを利用していたりしていて、TestRailにテスト結果の集約が完全にはできていません。テストの実績をTestRailで一元管理していくことを目指しています。

小山様：まだ十分に使い切れていない機能を活用していきたいです。TestRailを活用することで、日々の業務をより改善していくことができると考えています。今回のテスト管理ツールの導入により、将来的に実現したいことについても考える機会も得られ、次のステップを見据えることができました。

──今後、ブログなどを通じてTestRailの情報提供を強化していく予定です。ご期待いただければと思っております。本日は貴重なお時間をいただき、ありがとうございました。

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