テスト管理ツール「Qase」を導入して達成したことと残された課題

ツール導入で解決できたこと 1. Excel運用に付随する単純作業が格段に減った 2. 機能テストケース・テスト結果を一元集約できた 3. テスト結果分析において以前より高度なことができそう ツール導入後まだできていないこと・できなかったこと 1. 開発チームやPOにも編集者としてツールを使ってもらうこと 2. 自動テストのインテグレーション 3. 非機能テストの管理・結果集約 本記事は、みらい翻訳 Advent Calendar 2023の15日目の記事です。 こんにちは！QAチームのyaboです。大遅刻ですが8日目「QAエンジニアから見たTechnology Radar Vol.29」に続いての登板になります。 みらい翻訳の開発チームでは今秋より「Qase（ケース）」というテスト管理ツールを導入しました。 この記事ではQaseを数ヶ月利用したふりかえりも兼ねて、Qase導入によって解決できたこと、新たに分かってきた課題などをご紹介できればと思います。テスト管理ツール導入を検討している方のご参考になれば幸いです。 従来、みらい翻訳のQAチームではExcelを利用してテストケース（特にE2Eの機能テスト）を管理していました。これが組織サイズが成長するにつれて、Excelではいろいろつらくなってきたというのがツール導入の最大の理由です。 これはテスト管理における定番の課題ですので、どの組織でも同じようなことに悩んでいるのではないでしょうか。11月に開催されたオンラインイベント「テストケース管理ツール5社に聞く、おすすめテストケース管理術」においても、各ツールベンダ共通の見解としてExcelからの移行ニーズが最も大きいという旨が述べられています。 この記事でも上記動画等を援用してつらみ〜😅でおしまいにしてもいいんですが、改めて検討してみると、そのつらさも以下の3種くらいの課題に大別できるように思います。 Excelシート記入に伴う単純作業がつらい Excelファイルが散らばってつらい より高度なことをしようとするとつらい（テスト結果の分析、自動テストとの結果連携など） 弊社においては特に「課題2. Excelファイルが散らばってつらい」の点がなかなかクリティカルな課題です。 弊チームが各開発チームに実施いただいたテストケースや結果をどう管理するのか事前に明示できていなかったことが発端なのですが、結果としてクラウドストレージ（box）上のいろんなフォルダにテストに関するファイルが点在しており、一覧できない・検索もできないという状態になってしまっています。（何も知らない他チームの人からすると、いつなにをテストしたのかよく分からない・・・） このような状態は、他のメンバからのアドバイスが難しくなる、新しい要員の加入や交代に対応しづらくなる、など様々な問題へと繋がります。将来の組織拡大に向けても、このような状態は早めに脱したいものです。 これに加えて課題1や課題3もあり、これはもうテスト管理のプラットフォームとなるSaaSを入れてしまうのが一番合理的な解決策でしょうという判断に至りました。 ツール選定にあたっては、大まかに以下の基準で選びました。基準1-3はそれぞれ課題1-3に対応したものになっています。 単純作業軽減の目的のため、チケットとしてテストを管理できること 複数のプロダクトのテストケースと実行結果を一元管理できること Jira、Slack、各種自動テストツールなど、インテグレーションが豊富であること 特に基準 1 に関して、テスト管理ツールには大別するとチケット型とスプレッドシート型*1 が存在します。 個人的な肌感ですが、チケット型の方がスプレッドシート型で発生しがちなフォーマット管理などの単純作業は減る傾向にある気がしています。また弊社ではチケット駆動のアジャイル開発を実施していますので、開発チームへの展開なども見越すとテスト管理もチケット型の方が馴染みやすいだろうという考えのもとに今回はチケット型のツールで検討しました。 Qase は先に挙げた各基準をそれぞれ一定満たせている選択肢であり、かつ日本での採用事例も増えてきているなど環境的な追い風もあって、今回はこちらを採用しました。プランは有料プランの中では最安の Startup プラン (月額$20) からミニマムスタートしています。 なお、比較対象として TestRail を検討しましたが、価格や UI などの点で Qase の方が弊社には合っていると今回は判断しました。 どんなタイプのツールもそうなのかもしれませんが、チケット型を採用するかスプレッドシート型を採用するかを含め、〇〇というツールがどんなときも絶対的に良いんだ、とはならないので、実際に比較検討やトライアルをしてみてその時点で自組織に一番合うと思われるものを選ぶこと、そして時折市場をウォッチしてよりベターな選択肢はないだろうかと頭の片隅で考えておくことが大事なのかと思います。 さて、ここからは数ヶ月実際に Qase を使ってみてどうだったか、元々の課題は解決できたのかを振り返っていこうと思います。 1. Excel 運用に付随する単純作業が格段に減った まず最初に課題 1「Excel シート記入に伴う単純作業がつらい」に対しては良い解決ができ、Excel 運用に付随する単純作業は大幅に削減できました。 例えば、フォーマットを全シートに対して変更する、セルに色をつける、クラウドにファイルを上げ直す・・・など、無数の無駄な謎作業が Excel 時代は生まれていましたが、こうした作業はツールを入れればちょこっと設定すれば完了するか、そもそも作業として発生しません。またチケット単位やテストラン（テストの実行）単位で URL が発行されるので、テストケースやテスト結果の共有なども格段にやりやすくなりました。 そもそも Excel で管理しようとすること自体が間違いだったレベルで元が酷かったというだけなのかもしれませんが、QA メンバ内では「これだけでも価格ペイするよね、というか Excel に戻りたくない🤦♀️」という話が上がるほど好評な結果になっています。 2. 機能テストケース・テスト結果を一元集約できた 次に課題 2「Excel ファイルが散らばってつらい」に対しては、現状ある 1 プロダクトの E2E 機能テストに限定してではありますが、テストケースとテスト結果を集約することができてきました。 とりあえず Qase を見ればそのプロダクトの E2E 機能テストの情報は全部集まっているという状態となり、テスト設計・実装・結果確認などのテストプロセスが以前より楽に運用できるようになりました。特に、Qase の導入をしたプロダクトは新規開発フェーズであり、テストケースを追加・修正したり、同一のバックログに対して複数回テスト実施したりすることも多いので、同じことを Excel でファイルごとに分けて実施してたら多分運用で詰んでたな・・・と素直に思います。 ところで、現状この取り組みはその新規開発フェーズの1プロダクトに限定されている、と述べました。 これは純粋にマンパワーが足りていなくできていないというのもあるのですが、 展開したい先のプロダクトの開発プロセス上、費用面で見合わないかも？という課題が見つかってきました。 これが「ツール導入後まだできていないこと」その1に繋がります。 3. テスト結果分析において以前より高度なことができそう 最後に「課題3. より高度なことをしようとするとつらい（テスト結果の分析、自動テストとの結果連携など）」の テスト結果分析のところについては、明らかに以前よりもいろいろなことができそうだという実感を得ています。 Excelでは1ファイルの中に複数シートあると、テストケース数の集計すらいちいち関数を書いたりしないといけなかったので、 ツールが自動的に全体の値やFailしたテストケース数などの統計情報をパッと計算してくれるのはとても助かっています。 ダッシュボード機能など、まだ使いこなせていないところもあるので、 このあたりを深堀りしながらテストの状況の見える化・テストの改善に繋げていくつもりです。 ツール導入後まだできていないこと・できなかったこと 1. 開発チームやPOにも編集者としてツールを使ってもらうこと 現在、Qase上でテスト設計をするメンバはQAに限定しており、 開発チームメンバやPO(プロダクトオーナ)に対しては無償の閲覧権限を付与しています。 開発フェーズが進むにつれて、POにも受け入れテストケースを考えてもらったり、テスト実行部分を開発チームを移譲していきたいという気持ちはあるのですが、 Qaseがユーザ単位の課金体系であるため、テストをメインの業務としていないロールの人が契約しようとするとコスト面での採算分岐点のハードルが意外と高いです。 毎日テストに何らかの関わりがあるQAなら余裕でペイするものでも、週1回Qaseを触るか触らないかという方たちにも月$20（3000円程度）、となると 推進する側のQAから見てもちょっとお高いわね・・・と思ってしまうのが本音のところです。 この点に関しては正直現時点で妥当な解決策が見当たっていません。 取りうる選択肢としては完全な二度手間ですがQAがQase記入を代行する、とかでしょうか…。 2. 自動テストのインテグレーション これは「課題3. より高度なことをしようとするとつらい（テスト結果の分析、自動テストとの結果連携など）」に関係する事項です。 純粋にまだそこまで手が回っていないのでできていないという理由もあるのですが、優先度が低くなってしまっている理由として 「自動テスト結果をインテグレーションして何が嬉しくなるんだろうか？」という点がまだはっきりしていないという点があります。 QA側からすると、現状各開発チーム内でどんなユニットテストをしているのかブラックボックスになってしまっているというのは現状としてあるため、 そこを透明化していきましょうという触れ込みにはできるのですが、やろうとするとリポジトリ数も多いのでもう少し得られるメリットが多いと良いよね、とは思うところです。 Flaky（結果が不安定）なテストの自動判定などやってくれればいいのですが、その機能があるのかは現状まだ調査中の段階になります。 ここに関しては、E2E（エンドツーエンド）自動テストや API テストなど、QA チームが管理しているいわゆるテストピラミッドの上層部のテストから結果を統合してみて、どんなメリットがあるのか検討してから開発チームにも手伝ってもらうようなステップを踏むのがいいのかな、と考えています。 3. 非機能テストの管理・結果集約 最後に、Qase は明確に Pass/Fail がつけられるような機能テストの管理には向いているのですが、結果が線形になり、どこからの値が Pass なのか Fail なのか自体の議論がいるような性能（パフォーマンス）テスト、負荷テスト、また ZAP などで実行されアラートが上がってくるようなセキュリティテストの結果を集約するには向いていないなあと感じました。 セキュリティテストは無理にせよ、性能テストくらいは Qase で管理できないかなあと目論んでいたので、これはちょっと残念な点かもしれません。ここは割り切りとして、Confluence などでドキュメンテーションするという方向にしようと思っています。 以上がみらい翻訳で Qase を数ヶ月運用してみた感想になります。 細かい使い勝手でもうちょっと良くならないかな（例えば Jira との連携が仕様上微妙にやりづらいなど）と思うところもありますが、主として使っている QA エンジニアとしては概ね満足、他方開発チームから見ると多分「Excel から SaaS になったんだー」という程度の印象値になるのかなと推察しています。総合点数をつけるなら 70 点くらい・・・ですかね？ 個人的には 80 点くらいの水準を期待していたというのは本音としてありますが、そこまで活かし切るにはツール以上にこちらのマンパワーが足りていないというところも見えてきたところでした。使ってみて始めて分かったところも多いので、小さく始めて小さくコケることが大事よなあと改めて思わされた次第です。来年 Qase やテスト管理に纏わる施策をいくつか打ちながら、社内のテストプロセス・QA プロセスを改善できていけたらなと思っています。（いやはや、もう年末かいな・・・時が過ぎるのは早いものだ😭） みらい翻訳では一緒に地道な改善をできる QA エンジニアの方を随時募集しています。ご興味のある方はまずはカジュアル面談からで大丈夫ですので、下記リンクよりお問い合わせをお待ちしております！ *1: スプレッドシート型の代表例としては QualityForward, CAT などがあります。業界慣習によるものかもしれませんが、国内産はスプレッドシート型、海外産はチケット型がほとんどな気がしています。

テスト管理ツール「Qase」を導入して達成したことと残された課題

背景や根拠まで確認しますか？

調べる

選ぶ

サイト