モバイルリグレッションテスト改善について

はじめに

こんにちは！

クオリティマネジメントオフィスQCD第2グループ吉田と申します。

セーフィーでは様々なプロダクトがありますが、主にSafie Viewer for モバイルのQAを担当しております。今回はモバイルチームのリグレッションテストケース改善見直しについて書かせていただきたいと思います。先日Safie Viewer for PCの方でもリグレッションテストケースの改善についての記事を公開しましたが、今回はモバイルチームとしての取り組みを共有したいと思います。

Safie Viewer for PCの記事も合わせてご確認ください！ https://engineers.safie.link/entry/regression_test

はじめに
リグレッションテストとは?
モバイルチームの現状
取り組み
現在
今後について

リグレッションテストとは?

改めてリグレッションテストについてはJSTQBのシラバス(41p)で下記の様に定義されています。

修正および変更でコードの一部に対して行った変更が、同一コンポーネント、同一システム内の他コンポーネント、または他システムの振る舞いに意図せず影響を及ぼす場合がある。変更には、オペレーティングシステムやデータベース管理システムの新しいバージョンなど、環境の変更も含まれる。そのような意図しない副作用をリグレッションと呼ぶ。リグレッションテストでは、テストを実行して、そのような意図しない副作用を検出する。

Safie Viewer for モバイルでは、現在月一で定期的にリリースを行っており、1リリースで大小様々な機能を追加、不具合改修を行っております。リリースを繰り返す中で、悪い影響(意図しない影響)を与えていないか、既存の機能が問題なく動いているかを毎回実施しており、ここが実はすごく重要なテストになっております。

SafieViewer for PCのテックブログでも触れていましたが、毎月リリースをということで機能を追加すれば、それだけ次のリリース以降で確認するリグレッションテストケースに追加されていくことになり、月一のリリースの中で、実は一番時間がかかっているのもリグレッションテストだったりします。

モバイルチームの現状

そんな状態で、どんどんテストケースが追加していくと当然ながらテスト時間も追加していきます。そうして行く内にどうなるかというと、簡単に言うと「あれ、今まで時間内に終わっていたけどもしかしてテストが終わらない…?でもリリースは迫っている、残業するしかない！！？？」みたいなことがおこり得ることになります。

実際のテストケースですが、私が入社した2022年12月では600ケース程度だったものが、約2年経った2024年10月時点では1300ケース近くと約2倍に増加しておりました。 ※初期からテストケースの修正は重ねてはいるので、粒度は違いますが、それだけ多く追加されているということです。さらにAndroidとiOSでアプリ同時リリースをしているので単純に2倍の時間がかかります。

リリース	実施項目数
2022年12月 (v3.18.0)	623
2024年5月 (v4.13.0)	903
2024年10月 (v4.18.0)	1353

取り組み

さて、どうしようかと考えた時モバイルチームでは下記を取り組みました。

①自動化テストケースへの置き換え

以前から片手間で推進していた自動化を強制的に、メンバー全員でMagicPodによるリグレッションテストケースの自動化導入をすることで、手動でしかできないテストケース以外は自動化に置き換え、効率化を進めました。こちらはQCD第1グループの森重さんが中心になって進めてくれたおかげで3割程度が自動化で回せるようになっています!!こちらは森重さんの方でまた新たに記事にしてくれるはず！！自動化の理解が浅かったメンバーの育成から開始して結果としてモバイルチーム全体で大きな取り組みになりました！

②テストケースの優先度の見直し

今までも優先度自体は付与していたのですが、基準をより詳細にすることでチーム内で確認できるように再定義しました。

リリース後に不具合が出たらユーザー影響が高い機能(再生、デバイス設定、データ作成)などは優先度を高(Critical)に、毎回確認する必要がないようなエラー系や、閾値の確認などは優先度は低(Low)にするなど。再定義することでPJメンバーとも認識の共有もできたと思っています。

また、今回新たに【Medium01】【Medium02】としてローテーションという優先度を設定しました。これはリリース単位で毎回ではなく、ローテーションして実行するというケースです。

例えばモバイルアプリにはイベントを検知したらプッシュ通知が飛ぶようになっているのですが、このイベントには種類が複数あります。プッシュ通知が飛ぶという機能の仕組み自体は一つのイベントで確認できるので、複数のイベントを分割することで、1回に確認する量を効率化させる調整をしました。この様に新たな優先度を設定することでテスト内容を見直し、重要な機能により注力してテストを実行する様に調整をいたしました。

現在

取り組みを始めた後、1リリースに1300近くあったテストケースは900ケース弱くらいまで整理することができました！！自動テストを除外すると、現在約700ケース程を手動テストで実施しています。また、実施にかかる工数自体も削減でき、リソースが逼迫するということもなくなりました。【Medium01】/【Medium02】などのローテーションのケースに関しても、現状では大きな問題はなく、引き続き追加されるケースについては精査を続けて行きたいと思っています。