急成長を続けるメガベンチャーにおいて、複数プロダクトの品質を横断的に管理するQAマネージャーは、常に「スピードと品質の両立」という難題に直面しています。 各チームでバラバラに進む個別最適のテスト運用は、組織が拡大するにつれて端末依存のバグ見逃しや、手戻りによるリリース遅延といった大きなリスクへと姿を変えていきます。 こうした課題を根本から解決し、属人化を排した「持続可能な品質体制」を築くための鍵となるのが、モバイルデバイステストラボの存在です。 エミュレータでは再現できない実機特有の挙動を捉え、CI/CDパイプラインの一部として検証を自動化する仕組みは、QAを単なるボトルネックから価値創出の中核へと押し上げます。 そこで今回はメガベンチャー規模で求められるモバイルデバイステストラボの全体像を解説します。 自社構築（DIY）とクラウドサービスの比較、さらには失敗しないための運用チェックリストまで、現場と経営層の板挟みに悩むリーダーが「正しい方向」へ舵を切るための指針をまとめました。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼テストの種類について詳しい内容はこちら▼ 【保存版】テストの目的別タイプ一覧 モバイルデバイステストラボとは？ 一言でいう定義 モバイルデバイステストラボとは、スマートフォンやタブレットといった多様な実機端末を物理的あるいは仮想的に集約し、実際のユーザー利用環境に限りなく近い条件下でアプリケーションやWebサイトの動作を検証するための専用テスト環境を指します。 単に端末が並んでいる場所という意味に留まらず、OSのバージョン、画面サイズ、ハードウェアスペックの差異を網羅的に確認し、プロダクトの品質を組織横断で担保するための重要なインフラストラクチャとして機能します。 何を再現するのか この環境が再現するのは、開発環境では見落とされがちな端末ごとの挙動差と、ネットワーク環境などの利用状況に伴う現実の不確実性です。 具体的には、特定のメーカー独自のカスタマイズが施されたOSの挙動や、特殊なアスペクト比を持つディスプレイでの表示崩れ、さらには低速な通信回線や不安定なWi-Fi接続下でのパフォーマンス低下などをシミュレーションします。 これら「現実世界で起こりうる事象」を事前にラボで再現することで、リリース後の致命的な不具合やユーザー体験の損なわれを防ぐことが可能になります。 エミュレータ/シミュレータでは足りない理由 PC上で動作するエミュレータやシミュレータは、基本的なロジック確認やUIの概略チェックには非常に効率的ですが、ハードウェア固有の制限や実機特有の細かな挙動までは再現できません。 例えば、メモリ消費が激しい際のバックグラウンド処理の強制終了、バッテリー発熱によるCPUのクロックダウン、タッチパネルの感度やスクロールの滑らかさといった直感的な操作感は、実機でなければ正確に評価できません。 シミュレータ上では正常に動いていても、実機では描画遅延が発生するといった乖離は珍しくなく、品質の最終判断を下すには実機による検証が不可欠です。 似た概念との違い モバイルデバイステストラボと混同されやすい言葉に、デバイスファームやデバイスクラウドがあります。 これらは主に提供形態によって区別されます。 一般的にデバイスラボは、自社内や特定の拠点に物理的な端末を設置して運用するオンプレミスな環境を指すことが多いのに対し、デバイスファームやデバイスクラウドは、クラウドベンダーがデータセンターに用意した数千台規模の端末に、ブラウザやAPI経由でリモートアクセスして利用するサービスを指します。 自社で端末を資産として保有し、セキュアな閉鎖ネットワークで検証したい場合はラボ構築が選ばれ、多種多様な端末をメンテナンスコストなしで即座に利用したい場合はクラウドサービスが選ばれるという使い分けがなされます。 なぜ必要？導入で解決できる課題 端末/OSの多様化（フラグメンテーション）への現実的な対処 モバイル市場における最大級の課題は、OSのバージョンや端末スペックが多岐にわたるフラグメンテーションです。 特にAndroid OSにおいては、メーカー独自のカスタマイズや画面のノッチ形状、チップセットの性能差が顕著であり、特定の環境でのみ発生する挙動の乱れが頻発します。 モバイルデバイステストラボを導入することで、市場シェアに基づいた適切な端末ラインナップを戦略的に揃え、個別のプロダクトチームが場当たり的に端末を調達する非効率を解消できます。 組織全体で共通の検証基盤を持つことは、多様化するユーザー環境に対して抜け漏れのない品質基準を適用するための、最も現実的な解となります。 「ユーザー報告バグ」を同一端末で再現できる価値 リリース後にユーザーから寄せられる不具合報告の多くは、特定のOSバージョンや機種に依存したものです。 こうしたバグ修正において最も時間を要するのは「現象の再現」ですが、テストラボに豊富な実機が備わっていれば、報告されたものと同一の条件を即座に作り出すことが可能になります。 エミュレータでは再現しない実機特有の問題も、現物を用いることで確実に捉えられるため、開発チームは憶測に頼ることなく修正作業に集中できます。 この再現までのスピードアップは、MTTR（平均修復時間）の短縮に直結し、障害による事業損失を最小限に抑える大きなメリットを生みます。 安定したテスト環境が持てる 品質管理の全体最適を目指す上で、テスト環境の安定性は欠かせません。 個人の所有端末や開発者が共用している管理の不透明な端末では、バックグラウンドの設定や蓄積されたキャッシュがテスト結果に影響を及ぼし、不具合の切り分けを困難にします。 モバイルデバイステストラボとして一元管理された環境であれば、常にクリーンな状態や特定のネットワーク制約下での検証が保証されます。 これにより、純粋なアプリケーションのロジック不備なのか、それとも特定のハードウェア特性に起因するものなのかを正確に判別できるようになり、信頼性の高いテストエビデンスを積み上げることが可能になります。 CI/CD と相性が良い モダンな開発プロセスにおいて、テストラボは単なる「検証場所」ではなく、CI/CDパイプラインの一部として組み込まれるべき存在です。 プルリクエストが作成されるたびに、ラボ内の実機に対して自動でビルドがデプロイされ、スモークテストが実行される仕組みを構築することで、開発の極めて早い段階で不具合を検知できます。 リリース直前のQAフェーズで致命的な端末依存バグが見つかるという「手戻り」のリスクを激減させ、プロダクトのリリースサイクルを停滞させない持続可能な開発スピードを実現します。 これは、スピードと品質の両立を求める経営層やPdMに対しても、非常に説得力のある品質戦略となります。 自動化でカバー範囲と速度を上げる発想 プロダクト数や機能が増大し続けるメガベンチャーの環境では、すべての端末で手動テストを完結させるのは物理的に不可能です。 モバイルデバイステストラボの真価は、自動テストスクリプトを複数の実機に対して並列実行できる点にあります。 コア機能の回帰テストを自動化し、ラボの計算資源をフル活用することで、人間が介入する範囲を「探索的テスト」などの高付加価値な領域にシフトさせることができます。 手動の限界を認め、仕組みによってテストのカバー範囲と実行速度を底上げする発想こそが、属人化を排除し、組織として強固な品質推進リードを実現するための鍵となります。 方式の全体像 モバイルデバイステストラボには、DIY方式とReal Device Cloudなどの提供型サービスを活用する方法のふた通りがあります。 それぞれの詳細についてみていきましょう。 DIY（自社で端末を揃える）とは DIY方式は、文字通り自社で物理的な端末を収集し、オフィス内やデータセンターの一角に専用の検証スペースを構築することを指します。 単に机の上にスマートフォンを並べるだけでなく、安定して電源を供給するためのハブや、端末を固定するラック、そして各端末の状態をPCから遠隔で操作・監視するための仕組み作りが含まれます。 メガベンチャーのように複数のプロダクトが動いている環境では、誰がどの端末を借りているかを可視化する管理システムや、OSアップデートを制御する運用ルールまでを含めて一つの「ラボ」として定義されます。 DIYの強み 自社構築の最大の強みは、あらゆる要素を自社のコントロール下に置けるカスタマイズ性の高さにあります。 特定のUSB周辺機器を接続した状態での挙動確認や、社内独自のプロキシ環境、VPNを経由した通信テストなど、外部のクラウドサービスでは制限がかかりやすい特殊な検証条件を自在に組み上げることが可能です。 また物理的な距離が近いため、画面の光沢感やタッチの反応速度といった、数値化しにくいユーザー体験（UX）の評価を開発チームが即座に行える点も、プロダクトの質にこだわる現場にとっては大きな利点となります。 DIYの弱み 一方で、DIY方式は維持管理に多大なコストとリソースを要します。 端末を設置するスペースの確保だけでなく、空調管理や24時間稼働に耐えうる電源インフラの整備が必要です。 また、物理的な盗難や紛失を防ぐための高度なセキュリティ対策、さらには複数のプロダクトチームが同時にアクセスできるようにするためのシステム統合には専門のエンジニアリングスキルが求められます。 さらに、次々と発売される新機種への追従や、劣化したバッテリーの交換といったライフサイクル管理、世界各地のネットワーク遅延を模した環境再現の難しさなど、運用負荷が際限なく膨らむリスクを孕んでいます。 クラウド/提供型（Real Device Cloud等）の強み Real Device Cloudなどの提供型サービスを利用する最大のメリットは、端末調達と管理の負担を完全にゼロにできることです。 世界中のデータセンターに配備された数千種類の端末から、必要なOSや機種をブラウザ越しに選択するだけで、数秒後には検証を開始できます。 特にユーザーから報告された「特定の古い機種でのみ発生するバグ」の再現調査において、その端末を自社で所有していなくても即座にアクセスできる機動力は圧倒的です。 常に最新のフラッグシップモデルからニッチな低価格帯モデルまで網羅されているため、カバレッジの広さを重視するQA戦略において強力な武器となります。 では結局どう選ぶ？ 最適なアプローチは、すべてのニーズを一方の方式で満たそうとするのではなく、中核機能はDIY、広いカバレッジはクラウドで補完するというハイブリッドな発想を持つことです。 例えば、メインユーザーが集中する主要な5～10機種は手元に置いて日常的な手動テストやUX確認に活用し、ロングテールの多種多様な端末群や海外通信環境でのテストはクラウドへ外出しするといった設計です。 判断の軸としては、対象ユーザーの端末分布の偏り、社外にデータを持ち出せない等のセキュリティ要件、リリースまでのスピード優先度、そして専任の運用担当を置けるだけの予算と体制があるか、という4点を総合的に評価して決定するのが賢明です。 ラボの構成要素と作り方 目的設計 モバイルデバイステストラボを構築する際、最初に取り組むべきは「何を検証の主眼に置くか」という目的の明確化です。 手動テストによるUIやUXの確認をメインとするのか、あるいはCI/CDパイプラインに組み込んで大規模な自動回帰テストを回すのかによって、必要となる機材やインフラ構成は根本から異なります。 また、特定の高負荷状況を再現する性能テストや、多言語対応を確認するローカライゼーションテストを重視する場合も、個別の設定が必要になります。 目的が曖昧なまま端末を揃えても、結局は特定のチームしか使わない「部分最適」な環境に陥りやすいため、組織全体のプロダクトロードマップを見据えた全体設計が不可欠です。 端末選定 膨大な種類のモバイル端末をすべて揃えることは現実的ではありません。 まずは自社プロダクトのアクセスログや市場統計を分析し、ユーザーが実際に使用しているOSバージョンや画面サイズのシェアを把握します。 その上で、シェア上位の代表的な端末と、OSアップデートの影響を受けやすいフラッグシップモデル、さらにはスペックの低い安価な端末をバランスよく選定します。 また、モバイル市場は変化が速いため、一度購入して終わりではなく、半期ごとにラインナップを見直して古い端末を退役させ、最新機種を補充するローテーションの仕組みを運用ルールに組み込むことが重要です。 物理環境 実機端末を安定して運用するためには、物理的な設置環境の整備が欠かせません。 数十台の端末を常時接続する場合、スマートフォンのバッテリー膨張や発火を防ぐための適切な温度・湿度管理が必要になります。 また配線の混線を防ぐための整理棚や、各端末へ安定した電力を供給できる高品質な充電ハブの選定も重要です。 さらにメガベンチャーのような組織では資産管理の観点から、未発表プロダクトの情報を守るための物理的な施錠や入退室管理といったセキュリティ対策も無視できない要素となります。 これらは地味な作業ですが、持続可能なラボ運用のための土台となります。 ネットワーク環境 テストの再現性を担保するためには、ネットワーク環境を自在にコントロールできる設計が求められます。 単にWi-Fiに接続するだけでなく、必要に応じて有線LANアダプタを介した安定接続や、逆にパケットロスや低速通信を意図的に発生させるシミュレータの導入を検討します。 また、検証用サーバーが社内ネットワーク（VPN）内に閉じている場合、ラボ内の端末が安全にそれらのリソースへアクセスできる経路を確保しなければなりません。 外部の電波干渉を避けるための電波シールドボックスの導入も含め、どのような通信条件下でも一貫したテスト結果が得られる環境作りが、不具合の切り分けをスムーズにします。 運用ソフト/連携 物理的な環境が整った後は、それらを効率的に動かすためのソフトウェア層を構築します。 複数のプロダクトチームが円滑に端末を共有できるよう、端末の予約・貸出状況を可視化するデバイス管理システムや、自動テストの実行順序を制御するキューイングの仕組みが必要です。 テスト結果は自動的に収集され、JiraなどのバグトラッキングシステムやSlackへ通知されるように連携させます。 さらに、これらをCI/CDパイプラインと統合することで、コードの変更が即座に実機環境で検証される仕組みが整い、QAチームがボトルネックにならずに価値を提供できる体制が実現します。 自動化ツールの選択とメンテ ラボのポテンシャルを最大限に引き出すには、適切なテスト自動化ツールの選択が欠かせません。 Appiumなどのクロスプラットフォーム対応ツールは、iOSとAndroidでスクリプトを共通化しやすく、メガベンチャーにおける複数プロダクト展開に適しています。 ただし、自動化は「作って終わり」ではなく、OSのバージョンアップやUIの変更に伴うスクリプトのメンテナンスが必ず発生します。 ツール選定の際には、スクリプトの書きやすさだけでなく、保守性の高さやコミュニティの活発さも考慮すべきです。 継続的なメンテナンスコストをあらかじめ工数に見積もっておくことが、自動化プロジェクトを頓挫させないための現実的な戦略となります。 運用で失敗しないチェックリスト 維持管理 モバイルデバイステストラボを「作って終わり」にしないためには、日常的なメンテナンスを仕組み化することが不可欠です。 実機端末は常に通電状態にあるため、リチウムイオンバッテリーの膨張や過熱による故障のリスクが付きまといます。 週に一度の物理的な外観点検や、動作の重くなった端末の再起動といったルーチンワークを運用フローに組み込む必要があります。 またOSの自動更新を許可してしまうと、検証したいバージョンがいつの間にか上書きされてしまうため、更新のタイミングを厳格に管理するルール作りが重要です。 検証基盤がダウンして開発スピードを停滞させないよう、予備機の確保や故障時の代替フローをあらかじめ策定しておくことが、止まらない運用を実現する鍵となります。 セキュリティ 自社で端末を管理するDIY方式において、最も見落とされがちなのがセキュリティ対策です。 テストに使用したアカウント情報や個人情報に近いテストデータが端末内に残ることは、情報漏洩の重大なリスクとなります。 テスト完了ごとにデータを工場出荷状態に戻すか、専用のツールを用いてキャッシュやストレージをクリーンアップするプロセスを徹底しなければなりません。 またラボ内の通信を保護するための暗号化や、特定のエンジニアだけが高度な設定変更を行えるような権限管理も必須です。 物理的な端末へのアクセス制限と、デジタル面でのデータ保護の両輪を回すことで、メガベンチャーに求められる高いコンプライアンス水準を満たした品質基盤を構築できます。 スケール戦略 プロダクトの成長に伴って検証すべき端末数が増えると、設置場所の不足や管理工数の増大、OS更新の追従といった「規模の不経済」が顕著になります。 10台程度の管理であれば属人的な対応で回せても、50台、100台とスケールする段階では、手作業での管理は必ず限界を迎えます。 そのため、初期段階から将来的な拡張性を見据えた方式選定が重要です。 具体的には、物理スペースの拡張が難しくなった時点でクラウド型への移行を検討するか、あるいは管理自体を自動化するミドルウェアの導入を視野に入れておく必要があります。 組織が拡大しても品質担保のスピードが落ちないよう、ボトルネックの所在を常に予測し、先手を打ったインフラ投資の計画を経営層と共有しておくことが求められます。 チームで使える状態にする ラボの価値を最大化するには、QAチームだけでなく開発者やデザイナー、PdMが「いつでも、どこからでも使える」状態を整えることが重要です。 オフィスに出社しているメンバーだけでなく、リモートワーク中のメンバーも遠隔で実機を操作できる仕組み（リモートデバッグ環境）を導入することで、チーム間の連携は劇的にスムーズになります。 また、単にアクセスできるだけでなく「誰がどの端末に責任を持つのか」「貸出の優先順位はどう決めるのか」といったソフト面のルール化も欠かせません。 誰もが迷わずに検証環境を活用できる状態を作ることで、品質に対する意識が組織全体に浸透し、QAがボトルネックではなく価値創出のインフラとして機能し始めます。 まとめ モバイルデバイステストラボは、単なる端末の集合体ではなく、プロダクトの信頼性と開発スピードを支える「品質の心臓部」です。 その構築にあたっては、組織のフェーズや要件に応じて以下の3つのアプローチを検討する必要があります。 DIY向き： 高い統制や閉域網での検証が必須であり、特定の端末に深く最適化させたい場合 提供型向き： 端末の調達・保守負担を最小限に抑え、多種多様な機種へのカバレッジを即座に拡大したい場合 ハイブリッド向き： 主要端末は手元で深く検証し、ロングテールな環境はクラウドで補完する、現場で最も採用されやすい現実的な考え方 QAマネージャーとして市場価値を高め、組織内での信頼を勝ち取るためには、こうしたインフラを「全体最適」の視点で設計し、CI/CDやチーム運営の仕組みとして定着させることが不可欠です。 今回ご紹介した構築フローや運用チェックリストを、次四半期の品質戦略を具体化するためのフレームワークとして活用してください！ QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）

こんにちは！みなさん、テストしてますか？ 第2回の前編 では、E2Eテストの基幹部分とも言える 要素探索 の技術の変遷について扱い、 中編 では 実装 の技術の変遷について扱いました。 後編では、どのようにブラウザを介してWebアプリケーションを自動操作するのか、つまり 自動操作技術 について触れたいと思います。また、UIを自動操作して実施するテストという点から、E2Eテストには良くも悪くも様々な目的が期待されてしまっていましたが、これらはWebアプリケーション開発技術の変遷と共に徐々に変わってきました。こうした E2Eテストの目的 についても触れたいと思います。 記事一覧：モダンなE2Eテストの考え方をマスターしよう 【第1回・前編】まずはやってみよう – Playwrightを使ったハンズオン（事前準備編） 【第1回・後編】まずはやってみよう – Playwrightを使ったハンズオン（テスト自動化編） 【第2回・前編】E2Eテストの歴史 -要素探索技術の変遷- 【第2回・中編】E2Eテストの歴史 -様々な実装技術- 【第2回・後編】E2Eテストの歴史 -自動操作技術と目的の変遷 自動操作技術の変遷 さて、この連載では一貫してPlaywrightを使っています。PlaywrightはいわゆるE2Eテストフレームワークですが、大きく分けると「Webブラウザを自動操作するコンポーネント」と「自動テストを記述するコンポーネント」で成り立っています。 このうち、「自動操作」のほうには様々な変遷がありました。あまりに古いものは自分も良く知らない部分が多いので、おおむね2016年以降の主要なマイルストーンについて記載します。 Selenium 3 と Webdriver CDP（Chrome DevTools Protocol）とヘッドレスChromeを用いた自動テストの流行 開発者体験を重視したツールの流行 Selenium 3 と Webdriver Seleniumは、2025年現在で利用できるものの中では、もっとも歴史の長いブラウザ自動操作ライブラリです。複数のブラウザを統一されたAPIで自動操作できる、というのが強みで、たくさんのテストケースをたくさんのブラウザインスタンス上で実行するためのインフラも用意しています。 クロスブラウザの複雑性をライブラリ側で吸収するというアイディアと、ブラウザとSelenium Serverの中継ぎをするWebDriver部分は仕様を公開して各ブラウザベンダーに実装を任せるという思想そのものは良かったのですが、自動テストインフラの複雑さを招くことにもつながり、インフラの構築やメンテナンス、テスト実行時のトラブルシューティングなどの別の辛さを招いてしまうことも多かったです。 加えて、Selenium WebDriverの（少なくとも当時の）設計思想は「UI上で実際にユーザーが可能なインタラクションを模倣する」というものだったため、テストのためのモック/スタブを作りにくかったり、ネットワークスロットリングなどで特殊な環境を再現した上でのテストが難しいという弱点もありました。 また、仕組み上全てがHTTPベースのコミュニケーションになってしまう点もパフォーマンス上問題になるケースが多く、特にページロードや要素の表示待ちなどが非常に長くなるケースがありました。当時E2Eテストに「不安定」「遅い」という印象を持っていた人たちは、おそらくこれらに苦しめられたいたことでしょう。 一方で、色々と問題はありつつも、自動テストのための大統一APIを作るというビッグピクチャーに向けて今もなお前進し続けているプロジェクトであることは疑いの余地はなく、自動テストエンジニアとして生きるならぜひ動向を追い続けたいプロジェクトの一つです。 ちなみに、HTTPベースの単方向通信しか出来なかったのを改善するために、新しくWebDriver BiDiという仕様が策定されています。こちらについては後述します。 CDP（Chrome DevTools Protocol）とヘッドレスChromeを用いた自動テストの流行 ChromeがHeadlessモードをサポートしたことと、CDP（Chrome DevTools Protocol）をテストに使うことでSeleniumの弱点をカバーできると考えて、CDPをベースにしたハイレベルAPIを実装したのがPuppeteerです。当初はCDPを使っていたのですが、現在は後述するWebDriver BiDiを用いています。 Seleniumがあくまでユーザーに出来る操作のみにフォーカスしていたのに対し（参考： Selenium使いのためのPuppeteer解説｜Qiita ）、PuppeteerはCDPを用いるためネットワーク速度のスロットリングやスタブなど様々な開発者向け機能に対応しており、テストしやすさを改善していました。 一方で、Seleniumユーザーたちの多くがJavaやPythonなどでテストコードを書いていたのに対して、PuppeteerはJavaScriptのみの対応でした。これは普段UIを扱うフロントエンドエンジニアたちには自然だった一方で、JavaScriptの非同期APIに慣れ親しむ前の自動テストエンジニアたちにとってはかなり悩みのタネで、筆者も「自動テストスクリプトが順番通りに動いてくれない……おれはただテストを自動化したいだけなのに……」と毎日悪戦苦闘していたのを覚えています。 ちなみに、パフォーマンスの点について公平のために補足しておくと、Chrome/Chromiumブラウザの自動操作を担うWebDriver実装であるChromeDriverもまたCDPベースで実装されています。ですが、やはりWebDriver自体の通信がHTTP通信であることによるオーバーヘッド自体が大きかったため、速度の面でPuppeteerの方が有利でした。 また、SeleniumとPuppeteerの大きな違いとして、Selenium Gridのような大規模テストインフラを構築する機能の有無がありました。これは大量の実機テスト実行環境を束ねる目的では重要なのですが、CI/CD環境の中でChromiumをインストールしてテストを回すようなケースではそもそも不要なものでもありました。 開発者体験を重視したツールの流行 Cypress さて、Puppeteerの登場で、あくまで筆者の肌感ではあるものの、自動テスト界隈の人気は二分された印象がありました。 テストコードが書けるたくさんのテストエンジニアを中心にたくさんの自動テストを実行したい→Selenium 開発者が日常の開発サイクルの中でガンガンE2Eテストを回していきたい→Puppeteer そうすると、開発者はどうしても 開発者体験 の良さに目が行ってしまいます。例えば、ドキュメントが豊富であるとか、コードが書きやすいとか、デバッグ用のツールキットが充実しているとか、普段の開発エコシステムの中に組み込みやすいとか、そういった具合です。 そんな中で登場したのがCypressです。Cypressははフロントエンドの開発体験をウリにしたツールで、当時の開発者たちが慣れ親しんでいたjQueryのメソッドチェーンを踏襲した書きやすいAPI、フロントエンドエコシステムとの親和性、デバッグ体験の良さなど、良いところがたくさんありました。 一方で、仕組み上複数タブ・ウィンドウの切り替えが出来ないことや、クロスドメインiframeがテストできないことなどは、テスト対象のウェブサイトによっては致命的でした。ちなみに、Cypressのドキュメントは本当に徹底していて、これらのトレードオフまでつまびらかに解説されています。 Cypress docs： https://docs.cypress.io/app/references/trade-offs こうした課題はありつつも、上述した開発者体験の良さ、ならびにこうしたトレードオフまで充分に解説されたドキュメントなどは非常に開発者フレンドリーで、多くの開発者たちに親しまれていました（余談ですが、筆者はあるオンラインカンファレンスでCypressの中の人が「ドキュメントが充実しているのもCypressのいいところで、困ったことがあったらCommand+Kで一発で検索できる」と誇らしげに語っているのを見て、とても良いことだなと感心した覚えがあります）。 Playwright さて、Cypressのメジャーリリースとほぼ同時期に、本連載でも使っている Playwright がα版として産声を挙げました。自動操作の方法としてはPuppeteerが使っているCDPというものになるのですが、この方法は名前の通りChromium系のブラウザ（Chrome、Chromium、Edge）でしか使えないので、FireFoxやSafariはテスト用にビルドしたものを使っています。 個人的には非常にバランスの取れた、良い意味でいいとこ取りのツールだと捉えています。開発者体験の観点からCypressと人気を二分していましたが、その後Cypressと似た機能を取り入れることでより強力なツールになりました。 余談: Selenium4・Webdriver-BiDi 冒頭で紹介したSeleniumですが、何となくオワコンのように見えてしまいがちですが、きちんとメンテナンスされ続けており、2022年には待望の新メジャーバージョンが登場しました。本記事のPuppeteerの項目で「PuppeteerはCDPを直接触れるのでテストが楽」というようなことを書きましたが、Selenium4は待望の cdp エンドポイントが実装され、ブラウザによりますがCDPによる豊富なデバッグ機能にアクセスできるようになりました。 また、Seleniumの根幹となるWebdriver規格も進化しており、新たにWebdriver-BiDiというものが提案されています。BiDiはBiDirectional、つまり双方向の略です。SeleniumがHTTPベースの単方向通信のみのツールだったのを、Webdriver-BiDiはWebsocketベースの双方向通信のものに変えています。これにより、ページの表示待ちなどのパフォーマンスが改善しました。 Puppeteerの話の中で触れたとおり、現在PuppeteerはCDPベースからWebdriver-BiDiベースに変わっています。これがより進んでいくと、クロスブラウザテストのやりやすさはより高くなっていくはずです。 目的/役割の変遷 さて、この「E2Eテストの歴史」は、主にE2E自動テストで使われる技術の変化にスポットを当てることで、「本/記事によって書いてあることが全然違う」という状態を解きほぐすことを目的にしていました。締めくくりとして、これらの技術が何に対して使われるのかの変遷についても理解しておきましょう。 手続き的UIの時代: UIテスト = E2Eテスト JavaScriptによるインタラクティブな表現が可能になった直後のWebアプリケーションは、UIの変化をDOMツリーの操作によって行っていました。例えば、以下のサンプルは簡単なToDoアプリの実装です。ページ全体を読み込み直すことなく、ToDoアイテムの追加/削除のタイミングでデータをバックエンドサーバーに送信しています。 <div id="todoApp"> <input type="text" id="todoInput" placeholder="新しいタスク"> <button onclick="addTodo()">追加</button> <ul id="todos"></ul> </div> <script> function addTodo() { const text = $('#todoInput').val(); if (text) { // バックエンドにPOST送信 $.post('/api/todos', {text: text}, function(todo) { // 成功時にDOMに要素を追加 $('#todos').append(`<li data-id="${todo.id}">${todo.text} <button onclick="deleteTodo(${todo.id})">削除</button></li>`); $('#todoInput').val(''); }); } } function deleteTodo(id) { // バックエンドにDELETE送信 $.ajax({ url: `/api/todos/${id}`, method: 'DELETE', success: function() { // 成功時にDOM要素を削除 $(`li[data-id="${id}"]`).remove(); } }); } </script> DOMツリーを直接編集するということは、状態を再現させるためにはそこまでの手続きを再現させなければいけないということでもありました。再現させるためにはバックエンドも（データベースなども含め）完全なものを準備する必要があるため、必然的にUIテスト=E2Eテストという構図が生まれていました。 宣言的UIの時代: UIテストとE2Eテストの分離 一方、Reactに代表される宣言的UIフレームワークは、「状態を引数として受け取り、UIを返却する」関数としてUIを定義しています。同じToDoアプリをReactで書くと以下のようになります。 function TodoApp() { const [todos, setTodos] = useState([]); const [inputText, setInputText] = useState(''); const addTodo = async () => { if (inputText) { const response = await fetch('/api/todos', { method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify({text: inputText}) }); const newTodo = await response.json(); setTodos([...todos, newTodo]); setInputText(''); } }; const deleteTodo = async (id) => { await fetch(`/api/todos/${id}`, {method: 'DELETE'}); setTodos(todos.filter(todo => todo.id !== id)); }; return ( <div> <input value={inputText} onChange={e => setInputText(e.target.value)} placeholder="新しいタスク" /> <button onClick={addTodo}>追加</button> <ul> {todos.map(todo => ( <li key={todo.id}> {todo.text} <button onClick={() => deleteTodo(todo.id)}>削除</button> </li> ))} </ul> </div> ); } これにより、状態を再現させるための手続きを踏まなくても、特定の状態をテストできるようになります。 また、特徴的なのがUIをいくつかのコンポーネントのまとまりとして構成しており、各コンポーネントを分けてテストすることも可能である点です。子コンポーネントたちも親と同様に状態を受け取る関数として定義されているので、コンポーネントごとに状態を変えられるようになりました。 同時に、WebフロントエンドのビルドはバックエンドのWebアプリケーションフレームワークと別のフレームワークが担当することも増え、フロントエンドUIのみを分離してテストする傾向が増えてきました。その結果、純粋にUIの挙動だけをテストしたい場合はUIコンポーネントテストで済ませ、バックエンドとの統合における不具合の検知やCUJ（クリティカルユーザージャーニー: もっとも重要なユーザー導線）をE2Eテストで守る、という考え方が広まってきました。 まとめ この後編では、自動操作技術の変遷と、E2Eテストの目的の変遷について、流れを追う形でまとめてみました。 第2回はこれで終わりです。続く第3回では、E2Eテストが他のテストレベルとどう違うのか、どのような目的で行われるのか、どのように使い分けるべきなのか、などについて深堀りしていきたいと思います。 【連載】モダンなE2Eテストの考え方をマスターしよう 【第1回・前編】まずはやってみよう – Playwrightを使ったハンズオン（事前準備編） 【第1回・後編】まずはやってみよう – Playwrightを使ったハンズオン（テスト自動化編） 【第2回・前編】E2Eテストの歴史 -要素探索技術の変遷- 【第2回・中編】E2Eテストの歴史 -様々な実装技術- 【第2回・後編】E2Eテストの歴史 -自動操作技術と目的の変遷 The post 【第2回・後編】E2Eテストの歴史 – 自動操作技術と目的の変遷 first appeared on Sqripts .

こんにちは。システムエンジニアのバッサーノです。 私はここ1年ほどモバイルデバイスに関連したソフトウェアの開発業務に携わっています。 特に近年はテスト自動化への注目が高まっており、モバイルデバイスについてもテスト自動化の導入が進んでいます。 今回はモバイルテストの自動化をする上で最もオーソドックスなツールであるAppium（アピウム又はアッピウム）について、概要や使い方に触れていきたいと思います。 この記事がモバイルアプリのテスト自動化に興味がある方、導入を検討している方や勉強中の方の参考になれば幸いです。 1. Appiumとは？ 1.1. Appiumの概要 まずAppiumとは何か、形式的なところで言うと Appium は、iOS・Android向けのネイティブアプリ、ハイブリッドアプリ、Webアプリのテストを自動化するためのオープンソースツールです。 構造としては以下の図のようになっており、Appium Serverがテストスクリプトの命令を解析してAndroid/iOSデバイスを操作するコマンドへと変換し、デバイス上で指定した操作を実行してくれます。 またAppiumという名前からもわかるように、Webのテスト自動化で標準的に使用されているSeleniumベースの記法となっているため、すでにSeleniumを使用している方は同じような形式でAppiumのテストスクリプトを作成することができます。 1.2. Appiumの主な特徴 1.2.1. クロスプラットフォーム対応 iOS と Android の両方に対応し、同じテストコードで異なるプラットフォームをテストできます 1.2.2. 多言語サポート WebDriver Protocol に基づいているため、以下の言語でテストコードを記述できます Java Python JavaScript (Node.js) Ruby C# PHP 1.2.3. オープンソース Appiumはオープンソースで開発が進められているため、無償で利用することができます 1.3. Appiumを利用するメリット Appiumを使うことで以下の点を改善することができます。 自動化によってリグレッションテストのたびに同じ操作を繰り返す必要がなくなる iOSとAndroidで別々のツールを使い分ける必要がない CI/CDパイプラインにテストを組み込むことができる 2. Appiumを動かしてみる では実際にAppiumを使ってどのように自動テストができるのか、Appiumを実際にインストールして動かしてみましょう。 2.1. 事前準備 前項でも述べているようにAppiumはオープンソースであるため、無償でインストールして利用することができます。ここではサンプルとして以下の環境でAppiumを使用してAndroidのテストを実行してみます。 OS バージョン macOS 14.6.1 ツール バージョン 確認コマンド Node.js v20.19.1 node -v npm 11.6.2 npm -v JDK Java 8 java -version 2.2. Appium のインストール この記事の執筆時点（2025年11月）ではAppiumの最新バージョンは3.1.1であるため、今回はこのバージョンをインストールして使ってみます。使用するAppiumのバージョンによっては事前条件の各種ツールの必要バージョンも変化します。 # Appium本体のインストール npm install -g appium # インストールの確認 appium -v 出力例 : 3.1.1 2.3. UiAutomator2ドライバのインストール Appiumでは、プラットフォームごとのドライバを個別にインストールする必要があります。 # Android用UiAutomator2ドライバのインストール appium driver install uiautomator2 # インストール済みドライバの確認 appium driver list --installed 出力例 : ✔ Listing installed drivers - uiautomator2@6.3.0 [installed (npm)] なお、すでにAppium2系をインストール済みの場合は、ドライバのバージョンの競合などによりエラーが発生する場合があります。その場合はドライバの更新や再インストールなどを試してみてください。 2.4. Android Studioのインストール 今回はAndroid Studioのエミュレータを使用してテストを実行します。Android Studioをインストールされていない場合は公式サイトからインストールが可能です。 Android Studio公式サイト： https://developer.android.com/studio 2.5. 環境変数の設定確認 Androidツールを使用するためには環境変数が設定されている必要があります。以下のコマンドを実行し、JAVA_HOMEとANDROID_HOMEに正しいパスが表示され、PATHにそれらのパスが含まれていれば問題ありません。 # 環境変数の確認 echo $JAVA_HOME echo $ANDROID_HOME echo $PATH 未設定の場合は、以下を ~/.zshrc または ~/.bash_profile に追加します: # Java export JAVA_HOME=$(/usr/libexec/java_home -v 8) # Android SDK export ANDROID_HOME=$HOME/Library/Android/sdk export PATH=$ANDROID_HOME/platform-tools:$PATH export PATH=$ANDROID_HOME/cmdline-tools/latest/bin:$PATH export PATH=$ANDROID_HOME/emulator:$PATH # 設定を反映 source ~/.zshrc # または source ~/.bash_profile 2.6. Appium Doctorで環境チェック Appium Doctor を使って、環境が正しくセットアップされているか確認します。 # Appium Doctorのインストール npm install -g appium-doctor # Android環境のチェック appium-doctor --android 出力例 : info AppiumDoctor Appium Doctor v.1.16.2 info AppiumDoctor ### Diagnostic for necessary dependencies starting ### … info AppiumDoctor ### Diagnostic for optional dependencies starting ### … 「 ### Diagnostic for necessary dependencies starting ### 」のすべての項目に ✓ が表示されればOKです。 2.7. Androidエミュレータの準備 今回はAndroidエミュレータを使用してテストを行います。 Android Studioを起動 Tools > Device Manager を開く Add a new device… > Create Virtual Device をクリック デバイス（例: Pixel 5）を選択して Next システムイメージ（例: API 33 (Android 13)）を選択して Next (未ダウンロードの場合はダウンロードアイコンからダウンロードが可能) エミュレータ名を設定（例: Pixel_5_API_33 ）して Finish Device Managerメニューにある「 ︎」を押してエミュレータを起動する Android Studio上でエミュレータの画面が表示されればOKです。 また、以下のコマンドでデバイスの接続状態が確認できます。「emulator-5554」という文字列がこのデバイスを指定するためのシリアルIDとなっており、実機の場合もここがデバイス固有の値になります。 # 接続されているデバイスを確認 adb devices 出力例 : List of devices attached emulator-5554 device Status が device と表示されていればOKです。 2.8. Python環境のセットアップ Appiumは複数の言語のスクリプトに対応していますが、今回はその中でもPythonを使用してサンプルのスクリプトを作成します。 以下で必要なライブラリのインストールを行います。 # Appium Pythonクライアントのインストール pip install Appium-Python-Client # Seleniumライブラリ（依存関係） pip install selenium # pytest（テストフレームワーク） pip install pytest 2.9. テストスクリプトの作成 それでは、実際に実行するテストスクリプトを見ていきましょう。ここでは、以下のようなテストを作成しています。 Androidの標準の設定アプリを起動する 画面要素を探して標準出力する スクリーンショットを取得する 流れとしてはまず端末の指定するためのシリアルIDやテスト対象のアプリの指定などの各種情報をcapabilitiesに設定して、この後立ち上げるAppium ServerにHTTP通信してセッションを作成します。 そして、そのセッションを使用してテスト内の各命令を送信し、デバイスを操作してテストを実行します。 ファイル名 : test_android_settings.py from appium import webdriver from appium.options.android import UiAutomator2Options from appium.webdriver.common.appiumby import AppiumBy import time def test_android_settings(): # Desired Capabilitiesの設定 options = UiAutomator2Options() options.platform_name = 'Android' options.automation_name = 'UiAutomator2' options.device_name = 'emulator-5554' # adb devicesで確認したデバイス名 # 設定アプリを起動（アプリのインストール不要） options.app_package = 'com.android.settings' options.app_activity = '.Settings' # セッション開始までのタイムアウト設定 options.new_command_timeout = 300 # Appium Serverに接続 driver = webdriver.Remote('http://localhost:4723', options=options) try: print("✓ 設定アプリが起動しました") # アプリが起動するまで少し待機 time.sleep(2) # 現在のアクティビティを取得 current_activity = driver.current_activity print(f"✓ 現在のアクティビティ: {current_activity}") # 画面上の要素を検索（検索ボックスを探す） search_elements = driver.find_elements(AppiumBy.CLASS_NAME, 'android.widget.TextView') print(f"✓ 画面上に {len(search_elements)} 個のTextView要素が見つかりました") # 最初のいくつかの要素のテキストを表示 print("\n--- 画面上の要素 ---") for i, element in enumerate(search_elements[:5]): text = element.text if text: print(f"{i+1}. {text}") # スクリーンショットを保存 driver.save_screenshot('settings_app.png') print("✓ スクリーンショットを保存しました: settings_app.png") print("\n✓ テスト成功！") except Exception as e: print(f"✗ エラーが発生しました: {e}") driver.save_screenshot('error_screenshot.png') finally: # セッションを終了 driver.quit() print("✓ セッションを終了しました") if __name__ == '__main__': test_android_settings() 2.10. Appium Serverの起動 ここまででテストを実行する準備が整いました。早速テストを実行してみましょう。 手順としてはまずAppium Serverを先に起動します。 # デフォルトポート（4723）で起動 appium # または、ログレベルを指定して起動 appium --log-level info 起動成功時の出力例 : [Appium] Welcome to Appium v3.1.1 [Appium] The autodetected Appium home path: /Users/testkit/.appium [Appium] Attempting to load driver xcuitest... [Appium] Attempting to load driver uiautomator2... [Appium] Requiring driver at /Users/testkit/.appium/node_modules/appium-uiautomator2-driver/build/index.js [Appium] Requiring driver at /Users/testkit/.appium/node_modules/appium-xcuitest-driver/build/index.js [Appium] AndroidUiautomator2Driver has been successfully loaded in 1.403s [Appium] XCUITestDriver has been successfully loaded in 3.417s [Appium] Appium REST http interface listener started on http://0.0.0.0:4723 [Appium] You can provide the following URLs in your client code to connect to this server: http://127.0.0.1:4723/ (only accessible from the same host) http://192.168.3.13:4723/ http://192.168.64.1:4723/ http://172.32.1.15:4723/ http://172.32.1.34:4723/ http://172.32.1.26:4723/ [Appium] Available drivers: [Appium] - xcuitest@10.8.0 (automationName 'XCUITest') [Appium] - uiautomator2@6.3.0 (automationName 'UiAutomator2') [Appium] No plugins have been installed. Use the "appium plugin" command to install the one(s) you want to use. 注意 : Appium Serverは起動したままにしておきます（テストスクリプトは別のターミナルウィンドウで実行してください）。 2.11. スクリプトの実行 # スクリプトを実行 python test_android_settings.py 実行成功時の出力例 : ✓ 設定アプリが起動しました ✓ 現在のアクティビティ: .Settings ✓ 画面上に 42 個のTextView要素が見つかりました --- 画面上の要素 --- 1. Settings 2. Network & internet 3. Connected devices 4. Apps 5. Notifications ✓ スクリーンショットを保存しました: settings_app.png ✓ テスト成功！ ✓ セッションを終了しました 出力されたスクリーンショット(settings_app.png) このようにAppiumを使用することでモバイル端末上でアプリを起動し自動テストを実行することができます。実行時にAndroid Studioのエミュレータの画面をみてみると、実際に端末の設定画面が起動されるところも確認できると思います。 また、今回はAndroid Studioのエミュレータを使用しましたが、実機をADB接続することでエミュレータと同様に実機上でアプリをテストすることも可能です。 3. まとめ 本記事では、モバイルテストの標準的な自動化ツールとして、Appiumの概要を説明し、インストールから実際のテストコード実行までを解説しました。 Appiumは環境構築でのコマンドラインの操作やテストスクリプトの作成など、普段あまり触れない方にとってはとっつきにくい部分もあるかもしれません。実際に現在では様々なテスト自動化のGUIツールが存在し、コードレスに自動テストを作成することもできます。しかしAppiumは原始的な分、より柔軟なテストが作成できますし、自動テストの原理や流れを理解しやすいという点でも勉強して損はないと思います。 次回は、実機でのAppiumのテスト実行の手順や、より複雑なテストを作成するのに便利なツールの紹介をしていきます。 The post Appiumモバイルテスト自動化入門(1) 〜環境構築と初めてのテスト〜 first appeared on Sqripts .