サポートチームが複数の実機Androidで不具合を再現する方法

デバイス固有のAndroidの苦情を再現可能のカース、証拠パケット、および役立つエンジニアリングのハンドオフに変えるための実用的なサポートワークフロー。

サポートチームが複数のAndroid携帯を持っている理由は？

お客様は問題を正確に説明できますが、サポートチームが再現できない場合があります。アプリのバージョンが正しいかもしれませんが、問題は特定のメーカーのビルド、Androidバージョン、ディスプレイサイズ、権限状態、言語、ネットワーク、またはバッテリーポリシーでしか発生しません。単一の参照携帯電話では、その範囲を表すことはできません。これが、エンジニアリングがすでにエミュレータや自動テストを使用しているにもかかわらず、モバイルサポートチームが通常、小さな数の実際のAndroid携帯電話を保持している理由です。

目標は、すべてのモデルを所有することではありません。 3 つの質問を迅速に回答するために十分なカバーを維持することです。 チームはレポートを再現できるか、どの条件がそれをトリガーするか、およびサポート会話全体を繰り返すことなくエンジニアリングが継続できるようにする証拠は何ですか? AWS Device Farm も、開発者および QA チームとともにカスタマーサポート担当者を特定し、実際のデバイス間の相互作用を、カスタマーの問題をデバッグおよび再現する方法として説明しています。

• 認証、支払い、通知、許可、カメラ、Bluetooth、およびバックグラウンド処理の失敗。
• 特定の画面密度、フォントスケール、言語、またはナビゲーションモードで破損するレイアウト。
• Androidリリースまたはメーカーファームウェアに関連したアップグレードまたはインストールの問題。
• ネットワークの変更、Appのバックグラウンド化、バッテリー制限、または中断後にのみ発生する問題。
• エスカレーション前にスクリーンショット、短い録画、デバイス詳細、正確な再現手順が必要とされるお客様からのレポート。

電話機を選ぶ前に、最低限のケースデータを集めます。

ランダムな電話番号をクリックして開始しないでください。まず、サポート会話をテスト可能なケースに変換します。インテイクデータが欠落している場合、チームはデバイス固有の欠陥とアカウント、ビルド、ネットワーク、または古いデータの問題を区別できないため、物理的なデバイスの設定よりも多くの時間を浪費します。

お客様がすべてを提供できない場合は、空白を黙って埋めるのではなく、不明な点を記録します。サポートはまだ既知の経路をテストできますが、エンジニアリングはどのような仮定が立てられたかを見ることができるはずです。お客様におパスワード、支払い詳細、身分証明書、プライベートメッセージ、または関連のない個人ファイルを送信するよう依頼することは決してありません。

お客様の証拠から小さなデバイスマトリックスを作成する

便利なサポートデスクは、魅力的なフラッグシップ携帯電話の棚ではなく、顧客が実際に使用しているデバイスに基づいています。 アナリティクス、クラッシュレポート、チケットのボリューム、収益に重要なセグメントから始めます。 低価格のデバイス、一般的なミッドレンジモデル、最新のフラッグシップモデル、および未解決のケースで繰り返し表示されるメーカーまたはAndroidバージョンを選択します。

1. 信頼できる製品データから、トップデバイスモデルとAndroidバージョンをエクスポートします。
2. メーカーのファームウェア、パフォーマンスティア、画面特性、OS世代によって類似したデバイスをグループ化します。
3. 重要なケースの最大の割合をカバーする最小の物理セットを選択します。
4. モデルを追加するのは、チケットや製品のリスクがメンテナンスコストを正当化する場合に限ります。
5. マトリックスを四半期ごとにレビューし、意味のあるトラフィックやリスクを表していないデバイスを廃止します。

3～6台の電話デスクは、大規模なメンテナンスされていないコレクションよりも多くの場合、より便利です。より幅広い互換性を持つランは、まだクラウドサービスに送信できます。ローカルデスクは、高速なインタラクティブなレプリケーション、サポートデモ、および同じデバイスを繰り返し使用する場合に存在します。物理的なセットアップについては、を参照してください。低コストのAndroidデバイスラボガイド。

マルチ電話サポートデスクを整理する

各電話には安定した識別子が必要です。短いコードを割り当て、物理的にラベルを貼り、モデル、Androidバージョン、最後のリセット日、バッテリー状態、接続方法、インストールされたテストビルド、割り当てられたテストアカウントを記録します。複数の電話が1台のコンピュータを共有している場合は、信頼性の高いケーブルと電源付きUSBハブを使用してください。不安定な電力と損傷したケーブルは、アプリの欠陥に似た障害を引き起こす可能性があります。

複数のAndroid携帯を制御するチームで画面を比較したり、デバイス間で移動したり、承認済みの設定手順を繰り返したりする必要がある場合に、共通のワークスペースから行うことができます。 でLaiCai Screen Mirroring、デバイスは1つのWindowsまたはmacOSワークステーションから表示できるため、オペレーターは電話を拾う時間を短縮し、ケースの状態を比較する時間を増やすことができます。グループ化は、クリーンベースライン、アクティブサポートケース、低エンドデバイス、リセットを待っている電話などを分離するのに役立ちます。

• 比較用に、動作確認済みのベースラインデバイスを1台残しておきます。
• 可能な限り、合成データを使用した専用のテストアカウントを使用してください。
• 以前の状態が結果に影響を与える可能性がある場合、ケース間のアプリデータをリセットします。
• 電話番号コードは、すべてのスクリーンショットやケースノートに表示しておいてください。
• テストに影響を与える充電、USB、Wi-Fi、および温度条件を記録します。

制御された複製パスを実行します

有用な結果を得るための最速の方法は、通常、大量の同時アクションではなく、制御された比較です。最も近い一致するデバイスから始めて、お客様の開始状態を再現します。報告された手順を一度実行して、何も変更せずに実行します。問題が発生した場合は、頻度を確認するためにそれを繰り返します。問題が発生しない場合は、ネットワーク、権限、言語、アプリデータ、Androidバージョン、メーカー、フォントスケール、またはバッテリーポリシーのいずれかの変数を一度に変更します。

1. 電話コード、App のビルド、アカウントの種類、ネットワーク、言語設定、起動画面をケースカードに記載します。
2. 最も近い対応する電話で、お客様の正確な手順を再現します。
3. 動作確認済みのベースライン電話でも同じ手順を繰り返します。
4. 疑われる状態を 1 つだけ変更し、パスを実行し直してください。
5. トリガーが孤立した場合、または合意された試行制限に達した場合に停止します。
6. 成功と失敗の両方の試みを書き留めてください。否定的な証拠は次の調査を絞り込むことができます。

デバイスがすでに分離している場合は、同期入力を使用しないでください。権限ダイアログ、読み込みの遅れ、キーボード、または更新プロンプトは、同じクリックを異なるコントロールに送信する可能性があります。共有アクションは、選択されたすべての電話が目に見えて同じ安全状態にある場合にのみ役立ちます。そうでなければ、デバイスを個別に操作し、理解しようとしている違いを維持してください。

証拠パケットを作成し、エンジニアが再生できるようにします。

有用なハンドオフは、迅速にレビューできるほど小さく、再プレイできるほど完全である必要があります。1つのチケットは、環境、手順、観察された結果、予想される結果、およびサポートする証拠を結びつける必要があります。スクリーンショットは静的な状態を証明します。短いスクリーンレコーディングはタイミングと順序を証明します。ログは、インターフェースが表示できないことを説明します。これらはすべて、他を代替するものではありません。

チケットID、電話コード、ビルド、タイムスタンプを付けてファイル名を付けます。ハンドオフでは、エンジニアが複数のチャットスレッドを開かずに数分で障害を理解できるようにする必要があります。より広範なQAワークフローについては、モバイルアプリテスト用のAndroid画面ミラーリング。

ローカル電話、エミュレータ、またはクラウドデバイスサービスを選択します。

これらのツールは、さまざまなカバーリングの問題を解決します。ローカル電話デスクはクラウドデバイスファームの代替品ではありませんし、クラウドラボはサポートチームと一緒に慣れ親しんだ電話の価値を排除するものではありません。状態を忠実に再現できる最も安価な環境を選択してください。

実用的な順序は、迅速な健全性チェックのためにエミュレータを最初に使用し、可能性のある実際のデバイスによる原因のためにローカル電話を使用し、モデルが欠落している場合やケースの確認がより広範な場合のためにクラウドデバイスを使用することです。PCまたはMacでのAndroid画面ミラーリングサポートが必要な場合、分散型企業用車隊全体でのポリシー管理ではなく、ローカル電話に直接視覚的な制御が必要な場合に最も役立ちます。

複製中に顧客データを保護する

実際のデバイスのトラブルシューティングを行うと、プロセスが不注意な場合、個人情報が漏洩する可能性があります。デフォルトでは、合成アカウントとテストデータを使用してください。生産データが本当に必要の場合は、適切な権限を取得し、アクセスを制限し、ケースに必要なものだけをキャプチャし、会社の保留ポリシーに従ってください。AWSも、セッションがログやビデオを生成できるため、デバイスサービスでアカウントの詳細情報、個人情報、その他のセキュリティ関連情報を入力しないようにユーザーに警告しています。

• お客様のパスワード、支払い情報、認証トークン、プライベート写真、身分証明書をラボの電話にコピーしてはいけません。
• 証拠を添付する前に、関連のない名前、メッセージ、メールアドレス、アカウント番号をぼかしまたはトリミングします。
• テストアカウントは環境ごとに別々に保管し、会社のポリシーに従って認証情報をローテーションします。
• 保留期間が終了すると、スクリーンショット、録画、ログ、ダウンロードしたファイル、およびアプリデータは削除します。
• ポリシーで監査ログが必要である場合、機密性の高いケースにアクセスした人とその理由を記録します。

3台の携帯電話でワークフローをパイロットします。

電話の壁を購入することから始めないでください。 1 つの定期的なサポートケースのクラスと 3 つの代表的なデバイスを選択します。 動作確認済みのベースライン、最も一般的な顧客の電話、および対照的な低価格またはメーカー固有の電話です。 2 週間間ワークフローを実行し、パイロットがカバーできなかったケースを別のデバイスまたはクラウドサービスで解決できるかどうかを決定します。

1. デバイス不確実性により延期された最近のチケットを 10 つ選択してください。
2. 必要な入力フィールドと単一の証拠パケットテンプレートを定義します。
3. きれいなテストアカウントで、3台の電話機をラベル付けして準備します。
4. 最初の有意義な再現、説明ループ、エスカレーションの受け入れ、未解決のデバイスのギャップまでの時間を追跡します。
5. 実際に結果に影響を与えたのはどの電話機や環境条件か確認します。
6. 証拠が繰り返されるカバーギャップを示している場合にのみ展開します。

検証すべき結果はシンプルです。サポートエンジニアは、ケースを受信し、適切な電話を選択し、パスを再生し、いくつかの関連のないシステムを検索することなく、スタンドアロンなハンドオフを提供できる必要があります。共有されたローカルワークスペースがパイロットに役立つ場合、LaiCai Screen Mirroring選択したAndroidデバイスを1台のWindowsまたはmacOSコンピュータから表示し、制御できるようにします。

よくある質問

サポートチームはどのくらいの数のAndroid携帯が必要ですか？

実際のチケットと使用データから選択した3〜6台の電話から始めます。繰り返し発生し、重要なケースが現在のマトリックスまたは偶発的なクラウドセッションでカバーできない場合にのみデバイスを追加します。

すべての顧客レポートを再現できるかどうかをサポートする必要がありますか？

いいえ。深刻度、影響を受けるユーザー、ビジネスへの影響、セキュリティリスク、再発、および複製が次のアクションを変えるかどうかを優先順位付けします。デバイスラボは、漠然とした苦情をすべて再プレイする要件ではなく、意思決定ツールです。

同期制御で、すべての電話で同時にバグを再現できますか？

デバイスが目に見える状態で同じ状態にあり、操作が安全な場合のみです。タイミング、ダイアログ、権限、キーボード、レイアウトが異なる場合は、個別にデバイスを操作してください。違いは証拠であり、盲目的にクリックするものではありません。

LaiCaiはモバイルデバイス管理プラットフォームを置き換えますか？

番号。LaiCai Screen Mirroringローカルビジュアルコントロールとワークフローツールです。ゼロタッチ登録、ポリシー実行、アプリ配布、インベントリ、またはリモートワイプが必要な分散型エンタープライズフレートを展開している場合は、適切なMDMまたはEMMシステムを使用する必要があります。

ソース

• AWSデバイスファームのよくある質問
• AWSデバイスファーム開発者ガイド
• モバイルおよびウェブ用のOpenText機能テストラボ
• サムスンリモートテストラボ
• Google Android Enterpriseサポートガイダンス