Android バグレポートの書き方

再現可能な環境から始める

アプリのバージョンとビルド、Android バージョン、デバイスまたはエミュレーターのモデル、および関連する設定を記録します。パスワードや個人情報を含めずに、アカウントの状態とテスト データをメモします。古いビルドに関するレポートにはそのように記載されているはずです。

• テストした正確なビルドを特定します。
• 起動に必要な画面、アカウントの状態、ネットワークの状態を記録します。
• 大きなテキストや別の言語など、問題に影響する設定について説明します。

ステップごとに 1 つのアクションを記述します

他のテスターが到達できる状態から開始します。目に見えるコントロールと具体的な入力を備えた短い番号のシーケンスを使用します。無関係な問題は別のレポートにまとめてください。

• アプリを開き、影響を受ける画面に移動します。
• テスト値を入力するか、問題を引き起こすアクションを実行します。
• 目に見える結果とそれをどのくらいの頻度で観察したかについて説明してください。

期待される結果と実際の結果を分離する

期待される結果は、何が起こるべきか、そしてそれがなぜ妥当であるかを説明します。実際の結果は、あなたが見たものを記録します。根本原因が確認されていない限り、根本原因を仮定することは避けてください。重大度は影響を表します。チームは依然として修正の優先順位を決定します。

実用的な例: 非表示のフォームアクション

顧客の結果を測定したものではなく、例示的なシナリオです。テキスト サイズを大きくすると、フォーム アクションが固定パネルの下に落ちてしまい、到達できなくなります。有用なレポートでは、ビルド、ウィンドウ サイズ、テキスト設定、ナビゲーション ステップ、および予想されるスクロール動作が特定されます。編集されたスクリーンショットの参照がある場合は添付してください。

証拠を有用かつ安全に共有できるようにする

スクリーンショットまたは短い記録には、関連する状態が示されている必要があります。問題トラッカーでファイルまたはアクセス制御された添付ファイルを参照します。共有する前に、キャプチャとログから認証情報と個人データを削除してください。このウェブサイトは証拠をアップロードしません。

再テストでループを閉じる

修正後、新しいビルドで元の手順を再実行し、成功、失敗、または検証できなかったことを記録します。隣接するフローを回帰チェックに含めます。変更が加えられたという理由だけで問題を解決済みとしてマークしないでください。

これは Android システムのバグレポートと同じですか?

いいえ。これは個人または問題追跡者向けの構造化された問題の説明です。 Android システム バグレポートには診断ログが含まれており、Android ツールを使用して個別に収集されます。

ジェネレーターは私のアプリをテストしますか?

いいえ。独自のテストからの観察結果を入力します。ジェネレーターはそれらをフォーマットします。 APK の検査、デバイス ログの収集、欠陥の検証は行いません。

どこまで詳細にすれば十分ですか?

他の人が同じ状態に到達し、手順に従い、結果を比較するのに十分なコンテキストを含めます。レポートは 1 つの問題に焦点を当ててください。