自動化テストのリアル | [第6回]: スマホアプリの自動テスト

📱自動化テストのリアル：スマホアプリにおける実践的アプローチ完全ガイド（Appium + CI/CDで現場に導入するまで）

1. はじめに：テストの限界を超えるには、自動化しかない

現代のモバイルアプリ開発では、アジャイル開発・CI/CDの流れが主流になってきました。
ですがその一方で、手動テストに頼りすぎてボトルネックになっているチームも多く見受けられます。

たとえば、以下のような状況に心当たりはありませんか？

• 毎回、QAが画面遷移やバリデーションを目視確認
• テスト観点が属人化していて、引き継ぎが難しい
• テスト対象が広がるたびに人手が足りない
• バグ報告が後からユーザーから来る…

これらを打開する一手が「UI自動化テストの導入」です。

この記事では、以下を徹底的に解説します：

• スマホアプリにおけるUI自動テストの設計・実装
• AppiumとWebDriverIOの具体的なコード例
• CI/CDパイプラインへの統合
• 現場での運用ノウハウとトラブル事例
• テスト戦略の立て方と優先順位

---

2. スマホアプリのテスト戦略：理論ではなく現場ベースで考える

まず、スマホアプリにおけるテストの全体像を把握しましょう。
以下のピラミッド構造が基本戦略として推奨されます：

         [E2Eテスト]      ← UIレベルでユーザー操作を自動化（Appium）
       [統合テスト]      ← API連携・DBとの結合確認
   [ユニットテスト]      ← ロジックレイヤーの検証（最速・安定）

しかし実際の現場では、以下のような傾向があります：

• 単体テストは書かれていても、UIテストは後回し
• UI変更が多いため、UIテストが壊れやすい
• テスト工数が読みにくいため、スプリントに組み込めない

そこで重要なのが、「UIテストをスモークレベルで始める」というアプローチです。
たとえば：

• 「ログインできるか？」
• 「タスクが追加できるか？」
• 「設定画面が開くか？」

といった基本的な流れ（ユーザーフロー）だけをテスト自動化するだけでも、大きな価値があります。

---

3. Appium + WebDriverIO によるUIテスト構築（詳細手順）

3.1. Appiumとは？

Appiumは、iOSとAndroidの両方に対応した、クロスプラットフォームのUI自動テストフレームワークです。
内部的にはOSごとのUI自動化ツール（XCUITest, UiAutomator）をラップしており、Node.jsベースでテストを書ける点が魅力です。

3.2. 環境構築ステップ（React Nativeアプリの場合）

npm install -g appium
npm install --save-dev @wdio/cli @wdio/appium-service
npx wdio config

• iOS用： Xcode Command Line Tools が必要（xcode-select --install）
• Android用： Android SDK + Emulator + ANDROID_HOME 環境変数の設定が必要

3.3. wdio.conf.jsの設定（重要）

exports.config = {
  runner: 'local',
  port: 4723,
  specs: ['./test/**/*.spec.js'],
  services: ['appium'],
  capabilities: [{
    platformName: 'iOS',
    deviceName: 'iPhone 13',
    app: '/path/to/app.app',
    automationName: 'XCUITest'
  }],
  logLevel: 'info',
};

3.4. テストコードの実例（ログインフロー）

describe('ログインフローの確認', () => {
  it('正しいアカウントでログインできる', async () => {
    await $('~emailInput').setValue('[e-mail]');
    await $('~passwordInput').setValue('12345678');
    await $('~loginButton').click();

    // ログイン後画面に遷移したか確認
    const home = await $('~homeScreen');
    await expect(home).toBeDisplayed();
  });

  it('不正なパスワードではログインできない', async () => {
    await $('~emailInput').setValue('[e-mail]');
    await $('~passwordInput').setValue('wrongpass');
    await $('~loginButton').click();

    const error = await $('~errorMessage');
    await expect(error).toHaveTextContaining('認証に失敗しました');
  });
});

💡補足：React NativeでのtestIDの付け方

<TextInput testID="emailInput" />
<Button testID="loginButton" />

これを忘れるとAppiumから要素が見えず、“element not found”地獄に陥ります。

---

4. よくあるトラブルと現場Tipsまとめ

💥 問題例とその解決策

トラブル	原因	解決策
要素取得失敗	testID未設定 or 遅延表示	waitForExist, waitUntil, setImplicitTimeoutを活用
テストが遅い	アニメーションや無駄な待機	disableAnimations() や fastReset=true で高速化
テストが壊れやすい	UIが頻繁に変わる	Page Objectパターンでセレクタを統一管理
毎回ビルドが必要	Appのサイズが大きい	本番ビルドでなく、開発用ビルドで実行して時間短縮

🛠️ 現場で使えるTips集

• **Page Object Model (POM)**を導入し、テストコードの可読性・保守性を向上
• テスト用ユーザーをDBに事前登録しておくと、ログイン・認証テストが安定
• フレーク対策として、重要な部分にexpect().toBeDisplayed()で確認

---

5. CI/CDとの統合例（GitHub Actionsベース）

📦 サンプル構成ファイル：.github/workflows/e2e.yml

name: E2E Tests
on: [push]
jobs:
  test:
    runs-on: macos-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      - name: Install deps
        run: npm ci
      - name: Build App
        run: npm run build-ios
      - name: Start Appium
        run: appium &
      - name: Run E2E tests
        run: npx wdio run wdio.conf.js

🔔 失敗時のスクリーンショットを保存

afterTest: async (test, context, { error }) => {
  if (error) {
    await browser.saveScreenshot(`./errorShots/${test.title}.png`);
  }
},

CI結果をSlack通知やTestRail連携すると、チームでの共有もスムーズになります。

---

6. 拡張的応用：クラウド実行、A/Bテストへの応用

• BrowserStack や Sauce Labs で、実機シミュレーション
• テストケースのA/Bバリエーション作成で、デザインテストにも応用可
• スケジュール実行（毎晩9時にナイトリービルドに対してテスト実行）

---

7. まとめ：自動化テストは、仕組みを作れば回り出す

✅ メリットまとめ

• 手動テストの負担を激減、開発者が安心してリリースできる
• 品質担保が体系化され、属人化を解消
• 障害が出たときのトラブルシュートが高速化

⚠️ デメリット・注意点

• 導入初期は学習コストと環境構築コストが大きい
• UI変更に追従する運用設計が必要（バージョン管理含む）

---

📚 付録：テスト設計の優先順位ガイド（初心者向け）

優先度	テスト対象	理由
★★★	ログイン、サインアップ	全ユーザーが通る動線
★★	商品検索、投稿作成など主要機能	アプリ価値を支える中核機能
★	設定画面、プロフィール編集など	優先度は低いが壊れてはいけない

---

🔚 おわりに：まずは「1テスト」から始めよう

「完璧な自動化」を目指す必要はありません。
まずは1画面・1フローのテストを自動化し、CIに載せるだけでも十分な一歩です。

興味がある方は、以下のようなことから始めてみてください：

• npx wdio config でセットアップしてみる
• ログイン画面の自動テストを1つ書く
• GitHub Actionsに流してみる

---

📬 ご質問・リポジトリのサンプルが欲しい方は、コメントやDMで気軽にどうぞ！
実際のプロジェクトでのAppium導入事例なども、今後シリーズで紹介していきます。

---

👉（次回予定）
スクリーンショット比較でUIテスト