リグレッションテストを見直す

こんにちは。freee会計のQAエンジニアをしているbabaです。 freee QA Advent Calendar 2024 - Adventar 9日目です。

freeeでは、AppStoreとGooglePlay向けにモバイルネイティブアプリを展開しています。私は、その中でfreee会計アプリを含むいくつかのアプリを担当しています。

リグレッションテストの課題

モバイルアプリではリリース前に各ストアの審査が必要で、本番障害が起きた時に修正までのリードタイムがWebアプリより長くなってしまいます。そのためにバグを流出させたときのユーザ影響が大きくなりがちで、流出前にバグを検出するためのリグレッションテストの重要度が高いと考えています。

一方、freeeではモバイルアプリのテスト自動化をあまり進められていないため手動でリグレッションテストを行う必要があり、テスト工数を大量に注ぎ込んできました。

実際にはfreee会計アプリでは長年の積み重ねでテストケースが膨れ上がり、アプリのリリースの度に数十時間かけてリグレッションテストを行っており改善が必要な状況でした。

重篤度ベースでのテストケースの整理

freeeではバグがお客様に与えるよくない影響(インパクト)を重篤度として4段階で定義しています。開発チーム内で重篤度について話し合ったことで防ぐべき事象の解像度が上がったことを契機に、重篤度をベースとしてリグレッションテストを見直すことにしました。

※重篤度について詳しく知りたい方は、freee QA Advent Calendar 2024 - Adventar 8日目にymty-sanが公開したハッピーの重篤度でみんなで品質の目線合わせをするぞ！(ハッピーの重篤度でみんなで品質の目線合わせをするぞ！ - freee Developers Hub) をご確認ください

自身で作成した叩き台を元にチーム内で話し合った結果、最終的に以下の方針でテストケースを整理しました。

バグがあっても主要機能の利用を妨げない、重篤度が低い箇所のテストケースは基本的に削除する
上位プランのみ利用できる機能については削除しない
主要機能ではないものの、お問い合わせなどサポートにつながるための機能については削除しない

整理前に163項目あったテストケースは約90項目へと削減でき、テストに必要な時間も半分程度に減らすことができました。削減から1年弱経過しましたが、現時点で本番障害は増加していないため品質を落としすぎずに工数を削減できたと言えそうです。

ユーザの利用状況ベースでのテストケースの改善

重篤度ベースでリグレッションテストを見直すことでテストケースの大幅な削減に成功しましたが、まだテストケースを洗練できると考えていました。そこで、様々な分析基盤でユーザの利用状況を調査して利用頻度・回数を明らかにし、本番バグがユーザに与える影響を元にテストケースを調整することにしました。

Firebase Analytics Dashboard

freee会計アプリはFirebaseを組み込み、ログやクラッシュを収集しています。そこで、まず初めにFirebaseの機能を利用することにしました。 Analytics Dashboard内の表示回数のページでは各コントローラクラスの呼び出し回数を確認できるため、「想定以上にアクセスされている / されていない画面」が無いかどうかを絞り込めます。

確認したところアクセス数は想定より大きくずれていませんでしたが、「利用率は低いが、一部のユーザが頻繁にアクセスする画面」などを可視化することでユーザ理解に役立ちました。