本記事は、みらい翻訳 Advent Calendar 2023の15日目の記事です。

はじめに

こんにちは！QAチームのyaboです。大遅刻ですが8日目「QAエンジニアから見たTechnology Radar Vol.29」に続いての登板になります。

みらい翻訳の開発チームでは今秋より「Qase（ケース）」というテスト管理ツールを導入しました。

この記事ではQaseを数ヶ月利用したふりかえりも兼ねて、Qase導入によって解決できたこと、新たに分かってきた課題などをご紹介できればと思います。テスト管理ツール導入を検討している方のご参考になれば幸いです。

ツール導入前の課題

従来、みらい翻訳のQAチームではExcelを利用してテストケース（特にE2Eの機能テスト）を管理していました。これが組織サイズが成長するにつれて、Excelではいろいろつらくなってきたというのがツール導入の最大の理由です。

これはテスト管理における定番の課題ですので、どの組織でも同じようなことに悩んでいるのではないでしょうか。 11月に開催されたオンラインイベント「テストケース管理ツール５社に聞く、おすすめテストケース管理術」においても、各ツールベンダ共通の見解としてExcelからの移行ニーズが最も大きいという旨が述べられています。

youtu.be

この記事でも上記動画等を援用してつらみ〜😅でおしまいにしてもいいんですが、改めて検討してみると、そのつらさも以下の3種くらいの課題に大別できるように思います。

#	内容
課題1	Excelシート記入に伴う単純作業がつらい
課題2	Excelファイルが散らばってつらい
課題3	より高度なことをしようとするとつらい（テスト結果の分析、自動テストとの結果連携など）

弊社においては特に「課題2. Excelファイルが散らばってつらい」の点がなかなかクリティカルな課題です。

弊チームが各開発チームに実施いただいたテストケースや結果をどう管理するのか事前に明示できていなかったことが発端なのですが、結果としてクラウドストレージ(box)上のいろんなフォルダにテストに関するファイルが点在しており、一覧できない・検索もできないという状態になってしまっています。（何も知らない他チームの人からすると、いつなにをテストしたのかよく分からない・・・）

このような状態は、他のメンバからのアドバイスが難しくなる、新しい要員の加入や交代に対応しづらくなる、など様々な問題へと繋がります。将来の組織拡大に向けても、このような状態は早めに脱したいものです。

これに加えて課題1や課題3もあり、これはもうテスト管理のプラットフォームとなるSaaSを入れてしまうのが一番合理的な解決策でしょうという判断に至りました。

ツールの選定理由

ツール選定にあたっては、大まかに以下の基準で選びました。基準1-3はそれぞれ課題1-3に対応したものになっています。

#	要件
基準1	単純作業軽減の目的のため、チケットとしてテストを管理できること
基準2	複数のプロダクトのテストケースと実行結果を一元管理できること
基準3	Jira, Slackや各種自動テストツールなど、インテグレーションが豊富であること
基準4	なるべく安いこと

特に基準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プロセスを改善できていけたらなと思っています。（いやはや、もう年末かいな・・・時が過ぎるのは早いものだ😭）