リリース テスト計画は、重要なユーザー ジャーニーを特定のビルド、代表的なデバイス、記録された結果に結び付けます。チェックリストを出発点として使用し、それをアプリと変更のリスクに適応させます。
リリース候補と範囲を定義する
出荷する予定のビルドを正確に選択し、何が変更されたかを記録します。最も重要な操作フロー、サポートされている Android のバージョンとフォーム ファクター、および変更によって影響を受ける統合をリストします。どの地域が除外されるかに同意します。
代表的なテスト マトリックスを選択する
サポートされている対象ユーザー、利用可能な使用状況データ、加えている変更に基づいて、デバイスと Android バージョンを選択します。可能であれば、エミュレータと一緒に関連する実際のデバイスを含めます。 1 つの構成で合格した結果が、すべてのデバイスのカバレッジを確立するわけではありません。
最初に短いスモークテストを実行します
完全な計画に時間を費やす前に、インストール、起動、および 1 つの完全なコア ジャーニーを確認してください。ブロッキングの問題により有意義なテストが妨げられている場合は、正確なビルドに対してその問題を報告し、修正後にスモーク テストを繰り返してください。
テストの移行と障害パス
新規インストールと更新の動作、権限の選択、無効な入力、ネットワーク アクセスの中断を確認します。バックグラウンドを実行してアプリに戻ります。アプリ固有の購入またはアカウント フローの場合は、適切なテスト環境と専用アカウントを使用してください。
画面とアクセシビリティのバリエーションを確認する
サポートされている最小のウィンドウ、大きなテキスト、サポートされている方向、および関連言語を調べます。アクセシビリティを評価する際には、手動の TalkBack 体験を含めてください。自動チェックと手動使用では、さまざまな問題が明らかになります。どちらも単独では完全なアクセシビリティを確立しません。
リリースを決定する前に結果を記録する
期待される結果を確認した後でのみ、チェックに合格のマークを付けます。失敗したチェックをレポート参照とともに記録し、テストされていないチェックを未チェックのままにして、項目が適用されない理由を説明します。出荷責任者と修正内容と残りのリスクを確認します。
例: 変更されたサインイン フロー
計画の例: サインインの変更は、新規ログイン、無効な資格情報、期限切れのセッション、オフラインの再試行、およびバックグラウンドからの復帰に影響します。サポートされている言語と、その画面に最も関連する大きなテキストのバリエーションを追加します。候補ビルドに対して各結果を記録します。
QA と Google Play の資格を分けておく
このチェックリストは、品質テストを整理するのに役立ちます。これは、正式な Google 認定、セキュリティ監査、または Google Play テスター参加要件が満たされていることの証明ではありません。 Google Play の生産資格は別のプロセスです。
よくある質問
チェックリストを完了すると、アプリの出荷準備が完了したことを意味しますか?
いいえ。実行したチェックのみが要約されています。リリースの決定は、未解決の問題、除外領域、ユーザーのニーズにも依存します。
何台のデバイスをテストすればよいですか?
適用範囲を証明する普遍的なカウントはありません。サポート対象ユーザー向けの代表的な構成を選択し、テスト マトリックスの制限を文書化します。
チェックリストはJavaScriptなしで使用できますか?
はい。完全なチェックリストはページの HTML に含まれており、印刷できます。インタラクティブなステータスとマークダウンのエクスポートには JavaScript が必要です。
Android リリース テスト チェックリスト
18 Android のリリース チェック、結果、メモを記録します。チェックリストを Markdown としてエクスポートするか、印刷します。認定ではなく実用的なツールです。
ガイドAndroid バグレポートの書き方
既知のビルド、明確な手順、予想される結果と実際の結果、有用な証拠、および再テスト記録を含む、再現可能な Android バグ レポートを作成します。