freeeの開発情報ポータルサイト

テスト管理ツールを移行してみた 〜ツール転生させてQA無双〜

こんにちは。freee人事労務でQAエンジニアをしているnunです。
freee QA Advent Calendar 2024 19日目です。

昨年freee QA Advent Calender 2023にて下記テスト管理ツールの移行について投稿しました。 developers.freee.co.jp 本日はその後どうだったの?というところを投稿したいと思います。少し長いので必要に応じて後述の目次もご活用ください。

さて、タイトルでネタバレはしてしまっているのですが…
お陰様でTestRailからZephyr Scaleへのテスト管理ツール移行は無事完了しました!!!

結果として1年間がかりの対応となり、実際どういうことを行なったのか、何が大変だったのかといったあたりについて書いていきます。 Zephyr Scaleの使い方に重きを置いた以下記事もありますのでぜひ併せてご覧ください。 developers.freee.co.jp

おこなったこと

作業としては大きく以下がありました。

  • 新ツールの選定
    • 移行先の候補となるツールをピックアップする
  • 新ツールの確定
    • さまざまな観点から検討し移行するテスト管理ツールを確定させる

〜〜〜〜〜〜〜ここまで昨年の記事の内容〜〜〜〜〜〜〜

  • 新ツールの仮運用
    • 新ツールの使い勝手を確認するために、実際に業務で使用しているJIRAアカウントを用いて一部チームで使用する
  • 新ツールの運用方法調整
    • 使用した一部チームからのフィードバックを集め、どのように使っていくのが良いかを具体的に検討する
  • 新ツールの契約
    • 社内で利用するための申請と承認
      • freeeでは新ツールを導入する際に申請が必要であり、申請にてプライバシーポリシーや利用規約などを確認の上で承認となる
    • 稟議
      • 実際に何名が使用し金額がいくらになるのかを稟議にかける
    • 契約
      • 今回はAtlassian社の契約に相乗りしての契約となるので、そちらの窓口と調整をする
  • QAチームへの新ツールの全面展開
    • 使い方の展開
      • QAチーム全体への同期での共有、録画の共有
      • 使い方ドキュメントの充実化
    • 質問の受付先の設定
      • ask専用チャンネルを作成、他チャンネルで出た質問もそちらに集約できるように設定
    • 旧ツールからのデータ移行
      • 旧ツールのテストケースなどのデータを、プロダクトごとに設けたオーナーに主導してもらい移行
  • 旧ツールの解約
    • 過去データのバックアップの確保

思い返すとこんなに段階を踏んでいたんですね…。喉元過ぎると熱さも苦労も忘れるタイプの人間なので、頑張ってきた自分たちをちゃんと自分たちを褒めたいと思います。えらーい!🐧

ツール移行によって改善したこと

はじめに導入によって改善したことについて書いていきます。

JIRAとの連携

freeeではハッピー*1や開発のタスク管理にJIRAを活用しています。そのためJIRAとの連携がスムーズなZephyr Scaleになることで、開発のタスクへの紐付けや実行結果との紐付けが非常に使いやすくなりました。
またJIRAとの連携がシームレスとなりJIRAダッシュボードによる状況把握が可能となりました。ダッシュボードの作成によって、テストケースの実行進捗、PassやFailの割合の把握、ハッピーチケット一覧が一目瞭然となったのです。テストケースの数が多い場合などは特にこのダッシュボードが便利でした。

4つのガジェットが表示されている。テスト進捗ガジェットには154/156で98.7%の完了率が表示。テスト実行結果のガジェットではPass、Fail、In Progress、Blockedのステータスとその件数が分かる。テスト実行結果の時系列ガジェットでは何日に何件実行したかが分かる。JIRAチケットのフィルターガジェットもあり、ダッシュボードを見れば実行進捗と対応すべきチケットが一度に把握できるようになっている。
QAダッシュボードのスクリーンショット

使用可能なユーザーの大幅拡大

元々使用していたツールではQAメンバーの人数分の契約に留まっており、テストの実行状況はQAメンバーしかみられないクローズドな状態でした。そのためQA以外のメンバーへの共有時には、各QAメンバーが実行結果画面を抜き出したりそれを元に口頭で共有したりと一手間加える必要があったのです。freeeの価値基準「あえて、共有する」*2に逆らう形だったんですね。
それが今回JIRAアドオンであるZephyr Scaleに乗り換えることで、JIRA権限のあるユーザー全員が実行状況の一次情報を得られるようになりました。情報がオープンになるだけでなくQAメンバー以外もテストケースなどの操作が可能になったことで、なんだか新たな試みも生まれつつあるとかないとか…!?続報に期待ですね。
一方でこの誰でも触れる状態については不都合もあり、それは後述の大変だったことの部分で触れていきます。

コスト面

Zephyr Scaleに乗り換えることで、年間コストがマイナス50万円となりました。減りはしたけどそれくらいなのね〜と思いましたか?
前述の通りユーザーの大幅拡大があるにもかかわらず減額しているのであり、1ユーザーあたりで考えると……
年間コストはなんと20分の1となりました🎉🎉🎉
20分の1とはつまり20,000円が1,000円になるということで、ブラックフライデーもびっくりの減額だと思いませんか?こんなに減額されている物品だったら必須じゃないけど気になっていた、みたいなものなんかもここぞとばかりに爆買いしちゃいますよね。
社内向けに共有した際には大幅なコスト削減を示すグラフに大きな反響をいただきました。

年間コストと1ユーザーあたりの年間コストの縦棒グラフが横並びで表示されていて、1ユーザーあたりの年間コストはグラフの最上部まで伸びている旧ツールとほぼ見えない新ツールが並んでいてインパクトが強い。近くにはお金が浮いて喜ぶ家族のイラストが載っている。
新ツール乗り換えによる年間コストと1ユーザーあたりの年間コストのグラフ

さらに、移行後にはテスト管理ツール上での操作性向上による工数の削減などにより作業効率が改善したなどの嬉しい声もありました。自身としても新ツールの方が使い方に馴染むため、業務をよりスムーズに進められるようになって良かったです。
今後も新ツールへの理解を深め使いこなすことで、更なるQA無双を実現していきたいですね!

大変だったこと

続いて、導入において大変だったことを紹介します。

JIRAの契約に相乗りすることで生じた調整

前述のユーザーの大幅拡大の中でも記載している通り、Zephyr ScaleはJIRAのアドオンであるため、JIRAの契約に相乗りして契約できることとなりました。
その際に障壁となったのが、権限の制御です。契約開始当初はJIRAアカウントを持っているfreeers*3全員がテストケースなどを見ることができるだけでなく、Zephyr Scaleの有効/無効を変更できてしまう状況でした。実際知らないうちにZephyr Scaleが無効化され、Zephyr Scaleを操作していたのに画面をリロードすると表示できなくなるということが起こりました。利用者数が増える、すなわち不用意な操作が増えるということにもつながりかねないことから、Zephyr Scaleの有効/無効の操作権限を制御することにしました。

トグルボタンの隣にZephyr Scale is enabledと表示されている。
JIRAの特定のプロジェクトでZephyr Scaleの有効/無効を切り替えられる箇所のスクショ

権限の制御には一悶着あり、数多くの段階を踏むこととなりました。

  1. そもそも制御の方法が分からない
  2. JIRAのヘルプページを調べながら制限を掛けたが、思ったような制限にならない
  3. Atlassian社に権限制御手順のaskチケットを起票
  4. チケットでいただいた回答に基づき、その操作権限のある方を巻き込む
  5. 実際に制御を行う(事前にSandboxとしての立ち位置のプロジェクトのZephyr Scaleで制御されることを確認し、その後実際に使用しているプロジェクトのZephyr Scaleで制御の操作を対応)
  6. 制御の反映に時間が掛かったのか一部テストケースが閲覧できなくなる←!!!
  7. すぐに権限の制御を戻す
  8. 制御を戻す反映にも時間が掛かったようで、翌朝に全員がすべてを見られるように解消されたことを確認
  9. 土日で反映が終わることを期待して、金曜日の夜に権限制御をリベンジ
  10. 無事制御の反映が完了🎊

上記6.の通り、一時的にテストケースやテストランが閲覧できなくなってしまいました。事前に別途用意していたSandboxプロジェクトでは2,000テストケース、実際のプロジェクトでは80,000ケースと総量が桁違いだったために、事前には把握できず実際に試したときに閲覧できなくなるタイミングが生じたものと推測しています。

「自分また何かやっちゃいました?(原義)」という吹き出しと驚いた顔の人が載っている画像。
テストケースが閲覧できないとの一報を聞いてこの言葉が頭に浮かびました。

テストケースレベルの閲覧権限でなくプロジェクトレベルの閲覧権限の制御だったので、権限の反映中にテストケースを見られなくなることは予想外でした。権限制御は複数人を集め同期的に操作を行っていたことで、すぐに権限制御の取り止め(権限の付与し直し)をしようとアクションを決めて動けたのは良かったです。開発エンジニアが新規機能をリリースした際に稀に起こり得るというリバート作業もこんな気持ちなのかなと新鮮な気持ちになりました。

権限制御の対応を通して、複数人で同期的に操作を行なっていた点は良い点、操作の時間帯が夕方と操作者が多く万が一の場合のリスクヘッジをし切れていなかった点が改善点と、学びを得られました。

もし過去に戻ってやり直せるなら

実は前回の記事も今回の記事も、なろう系ラノベのタイトルを意識して書いています。昨今のなろう系ラノベあるあるでいうと、追放・転生と来てまだ欠けているアクションがありますね(※悪役令嬢要素や聖女要素はアクションでなく属性なので割愛)。

不思議な乗り物に乗った人が形が歪んだ時計に囲まれている画像。
時間が関係していそうなイラスト…ということは?

そう、タイムループです。
最後に、もし過去に戻れるなら何をやり直す?という点について記載したいと思います。
今回様々な方のご協力のお力添えにて正直そんなに大きくやり直すべきだと感じることや後悔していることは思い当たりませんでした。そのため少しミクロな部分になってしまうのですが、やり直すとしたら旧ツールの機能の最終確認を密に行いたいと考えています。事前にアンケートなどを用いてツール移行後も利用したい機能の収集は行なっていたものの、一部漏れていた機能や項目もありました。ツール移行後に自チームや周辺チームでは使用していなかった箇所について、普段のやり取りの遠い他チームでは活用していたので代替機能が欲しい、という事例が見つかったのです。結果的にそういった機能については後追いでZephyr Scale内で対応し活用できるよう整えられましたが、もしかするとまだ旧ツールで使われていて新ツールでは使用できていない項目や機能があるかも知れません。そのため移行前の最終確認として旧ツールの機能の把握を行い、新ツールに置き換えられるように整えらえたらと考えています。

まとめ

今回のツール移行対応を通して、新ツールの導入と移行のためには以下辺りが大事だと感じました。

  • メンバーからのツールへの要望収集
    • 現行ツールの良い点、現行ツールの使いにくい点、新ツールに求める点をヒアリングする
  • 新ツールの選定
    • 集めた要望を元にした自分たちの組織が求めている要望に対して合致するツールがいずれのものなのかを判断する
  • 移行時のメンバーへの共有(今回はあまり触れられませんでしたが、手厚めに準備していたおかげか新ツールの使い方や旧ツールからのデータの移行方法などに対して、質問が出ることがほぼありませんでした)
    • 新ツールのおまかな使い方を同期的に共有し、その録画も共有する
    • 新ツールの使い方と旧ツールからのデータ移行操作について、見れば機械的に操作できる粒度で画像付きのドキュメントを用意する
    • 不明点の質問やTips共有を目的とした専用のチャンネルを用意する
    • 同期的なぽちぽち会を開催し、その場で気になったことがあれば解消できる会を設ける
    • 導入後に、新ツールへの要望などを同期的に相談・解消する会を設ける
  • 旧ツールの仕様再確認
    • どんな機能があるかを最終確認し、新ツールで同じことができるかどうかを調整する

上記の中でも一番大事だと思ったのは、やはり新ツールの選定です。
率直に言ってしまうと、移行後のツールに対しても細かい部分での我々の要望に対して今少し届いていないのびしろの部分はあるように感じます。それでも旧ツールと比較して我々が求める機能をより備えていて使い方の要望にも合致しているという点を踏まえ、ツール移行には大変満足しています。

利用者が増えるとツールの使い方や求める機能が多様化し、誰にとっても100点満点で非の打ちどころのないツールを選ぶということが難しくなります。また他のツールを知れば知るほど「他のツールではこういうことができたのに」と欲深くなるものです。そういった要望をすべて叶えるためには、いっそ自分たちでツールを作るのも良いかも知れません(実はfreeeのQAの中でも作るという話が出て一部作成してくれた方もいました、すごすぎる)。

全員がツールに対して100%満足することは極めて難しいことを前提として、どこを大事にしてどこを譲歩できるのかを擦り合わせ、そこに合致するツールを選定していくことが大事だと強く感じました。

おわりに

今回のツール移行作業は私1人では絶対やり切ることができないほどの大きなものとなりました。昨年のツール選定から一緒に動いてくれた方をはじめ、関わってくれた方々のお力あってこその完遂です。人を巻き込むことの大切さ、一緒に進めていってくれる方の心強さを強く再確認しました。1人では難しいことも、人を巻き込み複数人であたることでやり切れるようになります。今後も困ったら(困る前でも)適宜周囲の方を巻き込んでいきたいと思いました。

明日は、QAエンジニアのyukky-sanが「権限管理基盤チームのCIの仕組みと課題」について記事を書いてくれます。お楽しみに〜! ではでは、よい品質を〜

*1:freee用語で不具合のことを指す

*2:https://jobs.freee.co.jp/about-us/culture/

*3:freee用語でfreeeで働いているメンバーのことを指す