エンジニアは「コードを書く」から「コードを検証する」役割へ
株式会社NTTドコモの子会社であるNTTレゾナントテクノロジーは、クラウド上で多種多様なスマートフォンの実機検証が可能なSaaS「Remote TestKit」を提供している。同サービスのプロダクトオーナーを務める角田和也氏が、生成AI時代のテスト自動化における課題や実機検証の重要性、そしてデバイスクラウドの選定ノウハウを解説した。
まず角田氏は「生成AI時代の品質保証の課題」を指摘した。生成AIによるコーディングが主流となった現在、「エンジニアの役割は、自らコードを書くことから、AIが生成したコードのレビューと検証へ移行している」と述べる。生成AIの活用により短時間で大量のコーディングが可能になり、生産性が向上したことは間違いない。
一方で、AIが生成したコードであっても品質の責任は人間が負う。コード量が増加し生成速度が上がれば、比例してバグ混入のリスクも増大する。実際、AI生成コードの内容を精査せずにマージしたり、セキュリティホールをチェックせずに開発を進行させたりするケースがあるという。
この課題を解消するために角田氏が強調するのが「テスト自動化の重要性」だ。ただし、AIが生成するテストコードは、AI自身が書いたコードをパスするように作成される傾向があるため注意を要する。角田氏は「E2Eテストは、最終的な要件との整合性を確認する観点から、人間が実施することが望ましい。実機テストも同様に人間による確認を推奨する」とした。
デバイスメーカー各社の独自実装やOSカスタムが引き起こす「実機依存」の不具合
角田氏はモバイル環境の断片化の状態を整理した「モバイル断片化マップ」を提示し、検証項目を5つのカテゴリで整理した。「UI／OS」「セキュリティ／認証」「ハード連携」「OSカスタム／電源」「ネットワーク／UX」の5つのカテゴリだ。
これらのリスクが実際の不具合につながった例も紹介された。例えば、F-Secure Labsの調査では、評価対象となったAndroidアプリの約70％が、有効な指紋なしで指紋認証を突破可能であることが明らかになっている。この要因は、製造メーカーごとに指紋スキャナーから認証APIまでの実装技術が異なっていた点にある。
OSのカスタマイズについても注意が必要だ。「XiaomiやOPPOなどの端末では、アプリがバックグラウンドに移動すると独自の省電力機能によりプロセスが強制終了されるなど、意図しない挙動を示す場合がある」と角田氏は指摘する。さらに、2021年3月に発生したWebViewのアップデート不具合による大規模障害を例に挙げ、外部環境の変化によるリスクを説いた。
「自分の知らない世界でアップデートが起きることによって、思いがけないバグが大量発生することもある。エミュレータのみのテストでは不十分であることを認識すべきだ」（角田氏）
ハードウェア依存の動作差異やメーカー独自のOS挙動を網羅するには、エミュレータでは限界がある。そこで、スマートフォンの実機をリモートで活用できる「デバイスクラウド」の選定が鍵となる。
戦略別に分類するデバイスクラウド5大カテゴリと選定ガイド
デバイスクラウドは、PCから遠隔で実機を操作しテストを実行できるサービスだ。角田氏は、各社の戦略に基づきサービスを5つのカテゴリに分類して紹介した。
- 総合力／大規模自動化：Sauce LabsやBrowserStackが該当する。世界各地にデータセンターを保有しており、グローバル展開を目指すチームに適している。
- エコシステム統合：インフラ管理の観点から、AWS Device Farmなどの既存クラウド環境と統合されたサービスを選ぶ選択肢だ。
- 体感品質／エッジ：HeadSpinに代表される。実ネットワークでの体感品質（QoE）やAV品質の計測が可能な点が特徴だ。
- AI差別化：TestMuなどは、生成AIを活用したテスト機能の拡充に注力している。
- 国内最適化：NTTレゾナントテクノロジーの「Remote TestKit」が該当する。日本国内のユーザー向けに設計されており、国産デバイスの豊富さと低遅延が強みだ。
こうした特徴を踏まえて、選定する際は「自社の最優先事項をもとに考えるべき」と角田氏。
「例えば、国内のコンプライアンスに従って、日本法に基づいたデータ主権が必要な場合はRemote TestKitが適している。一方、グローバル展開を見据えるならSauce Labsなどが選択肢となる」（角田氏）
角田氏は各クラウドデバイスの差別化ポイントと料金をまとめた表（以下）を示し、自社の条件に合ったものを選ぶことを推奨した。
デバイスクラウド運用を安定させる「4つのプラクティス」
ここまで各デバイスクラウドの強みを紹介してきたが、デバイスクラウドには利点だけでなく、特有のデメリットも存在する。主な課題は、ネットワーク遅延、デバイスの可用性、リソース制限の3点だ。
デバイスの可用性、つまり「他ユーザーとの端末競合による待ち時間」については、検証端末の条件を緩和することを提案した。例えば、iPhone 17を対象に自動テストを実行する場合、OSバージョンは26.0でも26.1でも許容するといった柔軟なデバイス指定にすることで、ほかユーザとの端末競合による実行失敗を回避できる。
リソース制限やセッション管理の問題に対しては、実装上の工夫が求められる。例えば数時間におよぶ長大なテストを実行する場合、シナリオを一定単位（10分程度）で分割して実行し、サーバー負荷による強制停止を防ぐ。
また、テストコード内で try-catch を活用し、異常終了時でも確実にデバイスを解放するよう考慮すべきだとした。
コスト管理においては、自社のSLAを定義して優先度の高い端末を絞り込むことや、固定Sleepなどの無駄な待機時間を排除する実装がポイントとなる。
Remote TestKitで提供する「Appium 自動テストクラウド」の価値
最後に、Remote TestKitの詳細が紹介された。同サービスには、テスト自動化フレームワーク「Appium」をクラウド上で実行できるマネージドプラットフォーム「Appium 自動テストクラウド」が含まれている。
Remote TestKitは、日本語による手厚いサポートと定額プランによるコスト予測のしやすさが特徴だ。国内最大級の端末カバレッジを誇り、700機種以上1200台以上の実機を備えている。
目指すのは、クラウド上の端末を手元にあるスマートフォンに近い操作感で使える開発体験だ。Appium 自動テストクラウドを利用すれば、煩雑な環境構築から解放され、エンドポイントの指定を含む数行のパラメータ設定だけで、Appiumテストのスマートフォン実機実行環境が整う。
デバッグ機能も充実しており、自動録画された動画とログを突き合わせることで、Appiumのリクエスト・レスポンスを詳細に確認できる。さらに、特定のAppiumバージョンの指定や、同一端末での連続テストを可能にするデバイス再利用設定など、独自のCapabilityも提供している。
「既存のローカルAppium資産があれば、エンドポイントとトークンの設定変更だけで5分程度で移行できる。帰宅前にテストを実行し、翌朝Web UIで結果を確認するといった運用が非常に効率的だ」と角田氏は締めくくった。
NTTレゾナントテクノロジー株式会社からのお知らせ
本セッションでご紹介したサービスにご興味を持たれた方は、ぜひ以下のサイトをご覧ください。
