Internal Testingとは何か、仕組み、トラックの設定方法

Internal Testingとは？

Internal Testingは、Google Play ConsoleとTestFlightにおけるテストトラックで、開発チームメンバー間でビルドを配布するために設計されています。オープンベータテストとは異なり、Internal Testingへのアクセスは、デベロッパーアカウント所有者が承認したメールアドレスのリストに制限されています。

主な利点は、テスターへの最小限のビルド配信時間です。Google Playでは、Internal Testingはモデレーションを通過する必要がなく、アップロード後5〜15分で参加者にビルドが表示されます。App StoreのTestFlightでも、ビルドは事前のApp Reviewなしで配信されますが、基本的なセキュリティ要件の自動チェックの対象となります。

Internal Testingと他のトラックの違い

Google Playには、Internal Testing、Closed Beta（Open Beta）、Productionの3つのテストトラックがあります。Internal Testingは最も高速で、参加者数が最も制限されています（最大100名）。Closed Betaは最大10,000名の参加者を許可し、テストページの設定が必要です。Productionは完全なモデレーションを伴う最終段階です。

Internal Testingを使用するタイミング

Internal Testingは、ベータトラックに移行する前の初期ビルド検証に使用されます。開発者は毎日のビルドをQAチームにアップロードし、新しいSDK統合を確認し、さまざまなOSバージョンとの互換性をテストし、ビルドが外部テスターに公開される前に回帰エラーを特定します。

Google PlayでのInternal Testing

Google Play Consoleでは、Internal TestingはRelease → Testingセクションで利用可能な独立したトラックです。テスターを追加するには、メールアドレスを入力するだけで、参加者はGoogle Play経由で参加するための招待とリンクを受け取ります。ビルドはプロダクションリリースと同じインターフェースを通じてアップロードされます。

内部トラックでの公開プロセス

開発者はGoogle Play ConsoleのInternal TestingセクションにApp BundleまたはAPKをアップロードします。システムは、署名、コードバージョン、API互換性などの基本要件をチェックします。5〜15分の処理後、ビルドがテスターに利用可能になります。ステータスはコンソールで追跡されます：下書き、レビュー中、テスト準備完了。

// Fastlane — Internal Testingトラックへの公開
lane :internal_testing do
    gradle(task: ":app:assembleRelease")
    
    upload_to_play_store(
        track: "internal",
        release_status: "completed",
        rollout: 1.0
    )
    
    slack(
        message: "Build uploaded to Internal Testing"
    )
end

テスターの管理

参加者の追加は、Google Play ConsoleのTestersセクションを通じて行われます。CSVファイルによるグループアップロードがサポートされています。各テスターは、招待状とインストール手順が記載されたメールを受け取ります。アクセスを取り消すには、グループから参加者を削除するだけで、インストール済みのアプリは引き続き動作しますが、新しいアップデートは届きません。

App StoreでのTestFlightによるInternal Testing

Appleのエコシステムでは、TestFlightがInternal Testingの役割を果たします。これはベータ版を配布するためのプラットフォームです。TestFlightは最大100名の内部テスターをサポートし、App Store Connectを通じてメールで追加されます。ビルドの公開に完全なApp Reviewは必要ありませんが、ビルドは最小要件に対して自動的にチェックされます。

TestFlight Internal Testingの特徴

モデレーションがまったく不要なGoogle Playとは異なり、Appleは自動基本レビューを実行します。チェックには30〜60分かかり、悪意のあるAPIのバイナリコードスキャンと基本要件の遵守確認が含まれます。チェックに成功すると、ビルドは24時間以内にテスターが利用できるようになります。ビルドの有効期限は90日間です。

App Store ConnectでのInternal Testingの設定

App Store Connectでは、Internal TestingはTestFlight → Internal Testingセクションで設定します。アカウント所有者はメールでテスターを追加し、ロールを割り当てます。XcodeまたはTransporterを介してビルドをアップロードすると、システムは参加者に新しいバージョンの可用性を通知します。テスターはデバイスのTestFlightアプリを介してアプリをインストールします。

Internal Testingトラックの設定方法

両方のプラットフォームでInternal Testingを設定するには10〜30分かかります。以下は、Google PlayとApp Storeのステップバイステップの手順です。このプロセスではアプリコードの変更は不要で、デベロッパーコンソールの一度の設定で十分です。

CI/CDシステムとの統合

両方のストアは、APIを通じたInternal Testingへの公開をサポートしています。自動化にはGradle Play Publisher（Google Play）とFastlane（両プラットフォーム）が使用されます。CI/CDパイプラインは、単体テストとUIテストの各成功実行後に内部トラックにビルドをアップロードできます。

テストアカウントの設定

認証が必要なアプリの場合は、テストアカウントを準備し、QAチームに提供する必要があります。アカウントはテスト環境（ステージング/開発）にアクセスでき、プロダクションデータに影響を与えないようにする必要があります。内部トラックには個別のテスト用Firebase設定を作成することをお勧めします。

Internal Testingを用いたQAワークフロー

Internal Testingは、CIでの自動チェックを通過した後、QAパイプラインに統合されます。開発者またはDevOpsエンジニアが内部トラックにビルドをアップロードすると、QAエンジニアは通知を受け取り、アプリストアを介してテストデバイスにアップデートをインストールします。

最適なリリース頻度

Internal Testingへのビルド公開は、毎日、またはコードベースに重要な変更があった後に行うことをお勧めします。QAチームは、認証、メインユーザーフロー、API統合、ローカルストレージ操作などの重要なシナリオをテストします。回帰テストは3〜4ビルドごとに実行されます。

フィードバック収集ツール

バグレポートを収集するには、トラッキングシステム（Jira、YouTrack、Trello、GitHub Issuesなど）との統合を使用します。テスターはスクリーンショット、ログ、再現手順を送信します。TestFlightには、デバイスを振った際のスクリーンショットとデバイスログの収集機能が組み込まれており、データはApp Store Connectを介して開発者に送信されます。

CI/CDパイプライン統合

Internal Testingトラックにビルドを自動公開するには、CI/CDパイプラインを設定します。単体テストとUIテストに合格した後、スクリプトがビルドを内部トラックにアップロードし、QAチームに通知を送信します。Fastlaneは、track: internalパラメータ付きのupload_to_play_storeアクションを提供します。iOSの場合は、Fastlane Pilotを使用してTestFlightにアップロードします。

Internal Testingの制限と上限

Internal Testingには参加者数の厳格な制限があります：Google Playでは最大100名、TestFlightでは最大100名の内部テスターです。Google Playはさらにグループ数を制限しており、内部トラックのグループは最大1つです。App Storeはビルド数を制限しませんが、各ビルドの有効期限は90日間です。

プラットフォーム間の制限の違い

Google Playは内部トラックにアップロードされるビルド数を制限しませんが、90日間非アクティブが続くと、トラックが自動的に停止される場合があります。TestFlightにはより厳しい制限があります：同時に最大30のアクティブビルド、最大10,000名の外部テスター（内部ではありません）。制限を解除するには、Apple Developer Enterpriseプログラムへの参加が必要です。

内部からオープンベータへの移行

内部トラックでビルドが安定した後、外部オーディエンスでのテストのためにClosedまたはOpen Betaに移行されます。Google Playではトラック設定をコピーし、再アップロードせずにビルドを転送できます。TestFlightでは、新しいテスターグループを持つ個別の外部トラックを作成する必要があります。

Internal Testingトラックのセキュリティ

内部トラックのビルドは外部アクセスから保護されています：Google Play ConsoleまたはApp Store Connectを通じて承認された参加者のみがアプリをダウンロードできます。たとえアプリのリンクを知っていても、承認されていないユーザーはビルドをインストールできません。これにより、新しい機能の機密性が確保され、開発段階での知的財産が保護されます。