ども。LDIの仙波です。スマホアプリの自動テストを担当しています。
久しぶりの記事投稿となります。

毎年の恒例行事としてAndroidのTarget SDKのアップデートがあります。この時期は保守メンバーが特に多忙になりますがリグレッションテストを担うテストメンバーにとっても一大イベントとなります。

弊社が開発を担当しているアプリ（以下、アプリ）は、Excelで作成した「既存リグレッションテスト仕様書」を使用して既存機能のリグレッションテストを実施していますが、当初は全て手動で実施していました。人手が足りない場合はスポットで外部に作業依頼したこともあります。

その後は積極的にUIテストの自動化を推進してきましたが、ここ2、3年はテスト自動化に技術的な課題があり、自動化率は40%台で伸び悩んでいました。今年は自社開発のテストツールである Shirates の技術的なブレークスルーがあり、自動化率を約50%に引き上げることができました。残りの50%は実機でしかできないテストであったり、マルチベンダのサーバー環境でテストデータのセットアップを自動化するのが難しかったりなど、未だ技術的・環境的な制約で自動化に課題があるため、現状で自動化可能なテスト項目についてはほぼやり切った形となります。

今年はそれ以外にも様々な課題を解決して万全の準備を行い、AndroidのTarget SDKのアップデートに伴うリグレッションテストに臨みました。

techblog.ldi.co.jp

2024年度のふりかえり

さて、2024年度の自動テストの実施作業が完了したのでふりかえってみます。

テストの実績

テストの実績を以下に示します。※数値は概略です

アイテム	実績	備考
サポートOS	Android 9-15 (7OS)	15はBeta版を使用
1OSあたりのテストシナリオ数	100
1OSあたりのテスト項目総数	1800
1OSあたりの自動化されたテスト項目数	1000
自動化率	56%
1OSあたりの実施時間（並列化なし）	6h (0.75d)
1OSあたりの実施時間（並列化あり）	1.25h (0.16d)
7OSあたりの実施時間（並列化なし）	42h (5.25d)
7OSあたりの実施時間（並列化あり）	8.75h (1.1d)

考察（工数）

現状の自動テストシナリオ全てをシングルプロセスで連続実行した場合、1OS分をテストするのに6h(0.75d)という少なくない時間が必要です。それでもテストツールは休憩なしで黙々と打鍵し続けるので、人間が打鍵するより速いと言えます。

仮に熟練者による手動テストの実施時間が自動テストの3倍（※休憩時間等のオーバーヘッド込み）かかるとすると、工数は0.75d x 3 = 2.25dかかる計算となります。熟練者ではなく全くのビギナーに応援に入ってもらった場合はその倍（4.5d）かかるかもしれません。さらに彼らをコントロールしサポートするための既存メンバーの工数（契約・管理・環境整備・教育など）が必要となります。

アイテム	実施時間(h)	工数(d)
1OSあたりの実施時間（自動テスト・並列化なし）	6h	-
1OSあたりの実施時間（手動テスト・熟練者, 係数:3）	18h	2.25d
1OSあたりの実施時間（手動テスト・ビギナー, 係数:6）	36h	4.5d
7OSあたりの実施時間（自動テスト・並列化なし）	42h	-
7OSあたりの実施時間（手動テスト・熟練者, 係数:3）	126h	15.8d
7OSあたりの実施時間（手動テスト・ビギナー, 係数:6）	252h	31.5d

既存のテスト要員＝熟練者とすると、既存のテスト要員1名に休暇なしで働いてもらったとして15.8d（3.2週=0.79月）が必要です。既存のテスト要員がアサインできない場合、応援要員をアサインすることになりますが、その人がビギナーだとすると単純計算で31.5d(6.3週=1.56月)が必要です。（作業しているうちに練度は上がりますが）

考察（実施時間）

上記では自動テストの実施時間を6hとしましたが、実際のテスト環境では自動テストはマルチプロセスで並列実行できるようにバッチを作成しています。テストを実行するマシンとしては入手できる最高スペックのMac Studio（M2 Ultra, 24コア, メモリ192GB）を導入しました。
※流行りのクラウドではなくオンプレミス環境ですが、コスパは最高です。

この環境において、Pixel 8(Android 14)のエミュレーターを8台同時起動してテストを実行しました。

各コアに負荷がかかっている様子

システム全体の負荷はこんな感じ（グラフ部分）

マシンスペック的にはまだ余裕があるものの、Androidエミュレーターを多数起動するとエミュレーターそのものやアプリがクラッシュしたり、Appiumのセッションが異常をおこしてテストが不安定になるので経験的にバランスが良いところで8台で運用していいます。（iOSシミュレーターの場合は10台で運用しています）

さて、実施時間の考察に戻ります。並列化された自動テストの実行に要した時間は以下となります。

アイテム	実施時間(sec)	実施時間(min)	実施時間(h)
ウォームアップ（エミュレーター起動、各種設定など）	300sec	5min	0.083h
テスト実施1回目	3500sec	58min	0.97h
テスト実施2回目（リカバリ実行）	700sec	12min	0.19h
合計	4500sec	75min	1.25h

1OS分の自動テストを実行するのに要する時間を比較すると以下のようになります。

構築した自動テスト環境は1台の物理マシン上でエミュレーターを8台同時実行しており、リソースの競合が発生するので単純に8倍速くなるわけではありませんが、並列化なしと比較して実施速度は4.8倍となりました。手動テストと比較すると14倍〜29倍程度の速度でテストを実施できていることになります。

このようにテストが高速実行できると、全シナリオを実施しても1OSだけなら1.25h、7OSでも1.25h x 7 = 8.75hで実施できます。テスト期間内で不具合が見つかって修正を実施した場合に、必要ならば全ての自動テストを再実施することで安心を得ることができます。これは手動テストだと事実上不可能ですが、自動テストだと実現可能な付加価値です。

自動テスト実行の並列化は効果が絶大であり、自動テストを運用する際に重要な要素であると言えます。

考察（正確性）

自動化されたテストは、実施結果が正確です。実装したこと以外は一切やってくれませんが、文字列比較のような人間が正確に行うことが難しいことを正確かつ高速に行うことができます。

手動テストは熟練したテスターなら初歩的なミスも少なく実施も早いものの、同じテストの実施を繰り返して慣れることで予断が生まれ、変化に気づきにくくなります。ビギナーであれば、初歩的なミスをする可能性が低くなく、注意深く正確に行おうとすれば非常に時間がかかります。

人間が行う必要性の低い定型的なテストは技術的に可能な範囲で自動化するのがよいと思います。

まとめ

アプリのリグレッションテストの自動化率は2024年度は50%を超えました
自動テストの並列実行により、手動テストに比べて14倍〜29倍程度のテスト実施速度を実現しました
AndroidのSDKアップデートに伴う7OS分のリグレッションテストの実施に必要な工数を大幅に削減しました。結果としてテスト期間の短縮につながり、プロジェクトに大きく貢献しました