リリース候補をフリーズしてテストする
バージョン番号とビルド識別子を決め、未反映の変更がないソースコードからリリース候補を作成します。初回起動、一回分のプレイの完了、設定、セーブデータの復元、中断と再開、新規インストールをテストしてください。対象とする画面サイズと向きで、すべての操作部を確認します。コードを変更した場合は再ビルドし、その新しい成果物に対して影響する項目を再テストします。デバッグ用ビルドとリリース候補が同じ動作をするとは限りません。
リストに必要な資料を収集します: アプリ名、説明、現在のビルドのスクリーンショット、年齢とコンテンツの回答、サポート連絡先、プライバシーの開示、およびアプリ内購入情報。ストアの現在のルールとターゲット要件がこの特定のリリースに適用されることを確認してください。固定のレビュー期間や古い API のカットオフに基づいてスケジュールを立てることは避けてください。
プラットフォームの段階的な提出ルートを使用する
Google Play の場合は、Play Console でアプリを作成し、ダッシュボードのセットアップを完了し、Android アプリ バンドルをアップロードして、適切なテスト トラックまたはリリース トラックを選択します。 Play Console のドキュメントには、パッケージ名は一意で永続的なものであるため、最初のアップロードの前に決定する必要があると記載されています。起動をスケジュールする前に、コンソールで現在のターゲット API とテスト要件を確認してください。
Apple の場合は、App Store Connect でアプリ レコードを作成し、ビルドを選択し、必要なメタデータを入力して、アプリ レビューに送信します。 TestFlight は、リリース前にベータ ビルドを配布し、フィードバックを収集できます。 Apple は、提出物にビルドを追加することと、実際に提出することを区別します。アップロードがすでにレビュー中であると仮定するのではなく、送信状態をチェックし、最終的なアクションが完了していることを確認してください。
リリースを繰り返し可能にする
リリース アーティファクト、ソース リビジョン、ビルド設定、変更ログ、提出メモを一緒に保存します。各ストアでどのバージョンが公開されているかを追跡します。 Web エディションも出荷する場合は、ホストされたルートとモバイル ブラウザーのレイアウトを個別にテストします。
モバイルゲームを公開するについての質問
両方のモバイル プラットフォームを一度にリリースする必要がありますか?
ビルドと送信の両方の準備ができている場合のみ。独立したプラットフォームのレビューとリリースの手順が異なる可能性があるため、利用可能なバージョンを明確に記載し、そのメモをプラットフォームに関連付けて保管してください。
同じテスト チェックリストで Web ゲームとストア アプリをカバーできますか?
一部のゲームプレイ チェックは共有できますが、パッケージ化、インストール、権限、更新、レビューの手順が異なります。一般的なゲームプレイのスモーク テストとプラットフォーム固有のリリース チェックを維持します。
関連情報
古い情報を見つけましたか？ 訂正を連絡