ライブラリアップデート時のテスト戦略再設計ー品質担保と効率を両立した話ー

はじめに

こんにちは。SansanモバイルアプリのQAエンジニアをしている中居です。

弊社は、「出会いからイノベーションを生み出す」をミッションに、ビジネスデータベース「Sansan」を提供しています。私たちQAチームは、Sansanモバイルアプリ（以降Sansanアプリ）の品質保証を担っています。

今回は、ライブラリアップデート時に実施していたテスト実行工数を削減した事例をご紹介したいと思います。実行テストケース数の削減やテスト対象のOSバージョンの見直しを行うことで、AndroidとiOS共にテスト実行工数を約65%ほど削減できました。

ライブラリアップデートのテスト実行に潜む課題

Sansanモバイルチームでは、これまでライブラリアップデート時テストの実施を3〜4カ月に1度の頻度で実行していました。一度の実行にiOSでは約4000テストケース、Androidでは約4800テストケースを15〜20人日ほどかけて実行していました。少なくとも2名のテスト実行者のリソースが3〜4週間ほど固定で拘束され、新規PBI（Product Backlog Item）のテストにリソースが割けない状態でした。また、セキュリティの観点から最低でも四半期に1回はライブラリアップデートをするように求められており、より高い頻度でライブラリアップデートを実施する必要がありました。

これらの課題を解決するために、一番インパクトが大きい「実施するテストケース数を最適化する」ことを最優先し、実施するテストケース数とOSバージョンの見直しを行いました。

課題に対する3つのアプローチ

課題を解決するために、次の3つのアプローチを行いました。

1. 使用しているライブラリに対する保証範囲を明確にする
2. 正常系を網羅したテストスイートを作成する
3. OSバージョンを絞る

1. 使用しているライブラリに対する保証範囲を明確にする

ライブラリアップデート時のテスト実行の方針として「ライブラリアップデート時は、影響範囲が読めないので全件テストを行う」というフローがこれまで確立されていました。

これまでライブラリアップデート時は、毎回4000〜5000ケースものテストが実行されており、最適化の余地がある状態だった
日々のテスト業務に時間が取られテスト内容について検討できていなかった

などの理由で、テスト内容の再検討がされていない状況でした。

そこで、使用しているすべてのライブラリに対して

全件テストを実施すべきか、それとも主要機能、一部機能のみ確認できれば良いか
OSバージョンはすべて網羅すべきか、それとも利用率の高いOSバージョンを重点的に確認できれば良いか

を、QAと開発で協議しました。

協議した結果、ほぼすべてのライブラリに関して全件テストほどの網羅性を持ってテストする必要がなく、特定の機能を確認すれば大方網羅できるのではないか、という話になりました。

というのも改めて使用しているライブラリを確認してみると、利用率が高くアプリのコアとなる機能（例えば、名刺撮影機能や人物詳細画面に関わる機能など）に対してテストができていれば、ライブラリ起因の不具合があった場合に検知できると判断したからです。

2. 正常系を網羅したテストスイートを作成する

ライブラリアップデート時に実施する新しいテストスイートの作成に取り掛かりました。

まずは、改めて「Sansanアプリにとって重要な機能、障害のリスクが高い機能は何なのか？」をQAチーム内で考え直しました。予め機能の利用率や利用頻度の高いシナリオは、社内のデータソースから把握できていました。しかし、会社として押し出したい機能や汎用性の高い機能も加味できていなかったので、それらを踏まえた上でライブラリアップデート時に重点的に保証すべき機能を定義し直しました。

また、ライブラリアップデート時に実施するテストケースに対するスタンスについてQAチーム内で認識を合わせました。「ユーザーが、シンプルなワークフロー（簡単な手順やステップで構成されるプロセス）で、問題なく操作できること」と定義し、メインシナリオである正常系の操作を網羅する方針にしました。

準正常系や異常系は、

過去3年のライブラリアップデートの実行結果から不具合が検出されていない
ライブラリアップデートの起因で、市場で不具合が検出されていない
利用頻度が高いシナリオではない
シナリオが複数条件で構成され、実行に時間がかかる

などの理由から省く判断をしました。これらのテストケースは、OSアップデート時に全件テストを実行する方針にすることで最低でも年に1回はすべてのテストケースを網羅する方針にしました。

正常系網羅テストスイートを作成する際は、具体的に次の観点を考慮しつつ全件テストの中からテストケースを選定しました。

ISO/IEC 25010品質特性
機能の利用状況や流入経路
ワークアラウンドの有無
本番環境で障害が起こった際のリスクや過去発生した障害

3. OSバージョンを絞る

テストを実施するOSバージョンの見直しも行いました。これまで推奨OSバージョンすべてに対して全件テストを実行していました。

利用率の高いOSバージョンは、iOS、Android共に最新バージョンと次に新しいバージョンであることがわかっていたので、それらのOSバージョンに対して正常系網羅テストケースを実施することにしました。それ以外のOSバージョンはよりコアな機能のみを網羅しているリグレッションテストを実施することにしました。

結果

上記の施策を実行した結果、以下の結果となりました。

Android

人日削減率：64%
実行テストケース数の削減率：64%

iOS

人日削減率：65%
実行テストケース数の削減率：59%

AndroidとiOS共に、人日は約65%、実行テストケース数は約60%ほど削減できました。これにより従来2名（iOS1名、Android1名）で15〜20人日かかっていたテスト実行日数が、7〜8人日ほどに短縮できました。また、この実行結果を受けて、ライブラリアップデートの頻度を4カ月に1回から2カ月に1回に変更できました。

振り返り

今回、長い間触れられてこなかったライブラリアップデート時のテスト実行の課題に着手しました。私自身入社間もなく不安の方が大きかったですが、開発、PdM、ベンダーの方々にヒアリングを行い情報収集しながら進めることができました。

「ライブラリアップデート時は影響範囲が読めないので網羅的にテストしたい」という不安は必ずあると思います。一方で「網羅的にテストしていたら工数がかかるし、効率的にテストしたい」という気持ちも強く、せめぎ合いが起こっていました。

このような状況の中、各ライブラリに対してどれくらいの保証を行うべきか、というアプローチを取ることで「本当はどこまでテストすればいいんだっけ？」を再度考え直すことができました。副次的にQA側が各ライブラリはどういった種類のライブラリなのかを把握することにもつながったので、アップデートされるライブラリの内容によって影響範囲の推測がある程度可能になりました。

テストスイートの作成に関しても、いくつかの観点を複合的に考慮することで、テストの網羅性を担保しつつ効率化できました。ライブラリアップデート時はどこまで保証すべきかや利用率、障害リスクの観点など、品質保証を検討するに当たり本来考慮すべき観点を踏まえてテストスイートを再検討することができました。