この記事では、当社のルールと基準に従ってバグを正しく記録する方法を学びます。お客様がバグを理解するためには、高品質なドキュメントと十分な情報が必要です。この記事の各セクションでは、当社のルールについてさらに詳しく説明していますが、ここではバグレポートの要件を簡単にまとめます。

バグレポートフォームで最初に行うべきことは、正しいFeatureを選択することです。ドロップダウンリストに正しいFeatureが表示されない場合は、テスト概要ページに戻り、すべてのFeatureの説明を確認して既読にしてください。その後、バグレポートフォームに戻ると、すべてのFeatureがドロップダウンリストに表示されます。

Featureを選択すると、バグフォーム全体が表示されます。たとえば、機能バグ用のフォームは次のようになります。

バグフォームのすべての項目には、当社の品質基準に従って正確で適切な情報を入力する必要があります。各項目とその要件の詳細については、以下をご覧ください。

機能バグ (Functional Bugs) の場合のみ、重要度 (Severity) という追加項目が表示されます。選択できる重要度は、低 (Low)、高 (High)、および 重大 (Critical) です。重要度はレポートの緊急度を示し、複数の要因によって決まります。各重要度レベルの詳細については、「機能バグ (Functional Bugs)」の記事をご覧ください。

重要度 (Severity) の項目は、その他の種類のバグでは表示されません。

バグレポートのタイトル (Title) は、タイトルを読むだけで読者が問題の概要を理解できるように、バグを要約したものである必要があります。バグが何であるかを理解するために、レポート全体を読む必要があってはいけません。バグレポートのタイトルは、正確かつ簡潔に記載してください。

バグタイトルを作成する際は、「何が起きていないか」ではなく、「何が起きているか」を記載してください。「動作しない」のような一般的な表現は避け、実際に観測された動作に焦点を当ててください。

タイトルは実際の問題を反映している必要があります。バグが特定の条件でのみ発生する場合は、その条件をタイトルに含める必要があります。たとえば、「ティーンエイジャー」であることを指定した場合にのみチケットを予約できないのであれば、その条件は重要な情報であり、タイトルに含める必要があります。

わかりやすいタイトルを作成するには、そのWebサイトやアプリを一度もテストしたことがなく、どのページを見ているのか、そのページがどのようなものか、何をしたのかをまったく知らない人の立場になって考えてみてください。その人の視点でタイトルを読み、バグを理解できるかどうかを確認してください。バグの内容が十分に伝わらない場合は、タイトルを修正し、同じ手順を繰り返してください。

バグが発生するページにアクセスし、ブラウザーのURL欄 (URL field) からURLをコピーして、バグレポートフォームのURL欄 (URL field) に貼り付けてください。URLは有効なものである必要があります。

バグは再現可能である必要があり、再現方法を説明する詳細な手順を順番に記載する必要があります。各手順では、1つの操作のみを説明してください。

最初の手順には、Webサイトをテストする場合はAccessセクションで提供された顧客環境のURLへアクセスすることを、モバイルアプリをテストする場合はアプリ名を含めてアプリを開くことを記載する必要があります。

Webサイトの場合:

モバイルアプリの場合:

それ以降の手順では、最初の手順からバグが発生するまでに実行した操作を記載してください。どのボタンを押したか、どのリンクをクリックしたか、何を入力したかなどを記載します。最後の手順には、バグを引き起こす操作を記載する必要があります。

手順はできるだけ一般的に記載してください。特定の商品一覧ページ、特定のフィルター、特定の入力など、特定の条件でのみバグが発生する場合に限り、その条件を手順に含めてください。たとえば、問題がすべての商品で発生するのであれば、手順には訪問した特定の商品一覧ページや、カートに追加した特定の商品を記載しないでください。これにより、読者はバグの内容を理解しやすくなり、関係のない詳細に気を取られることがなくなります。

最後に、手順に含める操作はできるだけ少なくしてください。報告されたバグを再現する人は、各手順を読んだ後、その内容をWebサイトまたはアプリ上で実行できる必要があります。同じ手順を何度も読み返して何をすべきか思い出す必要があってはいけません。

実際の結果 (Actual Result) は、バグレポートの中で最も重要な項目の1つです。この項目では、問題が何であるか、およびバグを理解するために必要な詳細情報を説明します。

再現手順に従った後に実際に何が起きるかを、できるだけ詳しく記載してください。できるだけ正確に記載し、「並び替え方法Xを適用しても商品はほぼ同じ順序のままである」のような一般的な表現ではなく、正しい順序になっていない具体的な商品の例を記載してください。また、例、追加の条件、例外、または必要に応じてその他の重要な結果など、バグに関連する情報があれば、この項目に追加してください。ただし、読者が内容を理解しやすいように、情報を整理して記載してください。

同様に、実際の結果 (Actual Result) はレポートのタイトル (Title) と同じ内容であってはいけません。タイトルは問題の要約ですが、実際の結果はその詳細な説明であり、再現手順を実行した際の状況、具体例、および得られた結果などの追加情報を含める必要があります。

最後に記載した手順を実行した後に、どのような結果になることを期待するかを記載してください。バグが発生せず、すべてが正常に動作した場合に何が起きるべきだったかを考えて記載してください。

期待される結果 (Expected Result) は、実際の結果 (Actual Result) を少し言い換えたり、否定表現にしたものではありません。この項目は、バグを再現する最後の手順を実行した後に、本来起こるべきだったことを説明するためのものです。

バグに添付する必要がある添付ファイルの種類と適用されるルールについては、「バグレポート添付ファイルの要件」の記事をご覧ください。

バグが発生した際に使用したデバイスを把握することは、当社およびお客様にとって重要です。Webサイトをテストする場合は、使用したデバイスの横にあるブラウザーアイコンをクリックしてください。モバイルアプリをテストする場合は、テストに使用し、そのアプリがインストールされているデバイスを選択してください。
​

この項目に表示されているデバイスのみをテストに使用できます。また、バグを報告する際は、デバイスまたはブラウザーを1つだけ選択し、その環境で取得した添付ファイルのみをアップロードしてください。他のデバイスやブラウザーでもバグを再現できる場合は、その旨を実際の結果 (Actual Result) に記載してください。

バグが発生した正しい使用環境 (Used Environment) を選択することは必須です。レポートを送信する際は、正しい使用環境を選択していることを確認してください。誤った使用環境を選択した場合でも、送信後に修正できます。チームリーダーがバグレポートをレビューする前であれば、使用環境の選択を変更することで修正できます。バグレポートに誤った使用環境が選択されている場合、チームリーダー (TL) はレビュー時にそのレポートを却下します。

プロフィールの利用可能なデバイス一覧に含まれていないデバイスでテストしたい場合は、Supportチャットからリクエストを送信してください。お客様にとって関連性があるデバイスであれば、利用可能なデバイス一覧に追加します。

レポートを送信した後でも、選択したバグタイプ (Bug Type) を除き、すべての項目を編集できます。ただし、レポートは必ずレビュー可能な完全な状態で提出してください。編集 (Edit) オプションは、小さな入力ミスを修正したり、表現を見直してレポートの品質を向上させたりする場合にのみ使用してください。

バグが特定の入力でのみ発生する場合は、実際のユーザーが使用するような表現を使用し、バグレポートや添付ファイルを作成する際に無意味なキーワードを入力しないでください。たとえば、顧客のインターフェースでアカウントを作成する際に、「asdsdfkg_lajsdh」のようなユーザー名を使用するのは好ましくありません。このような入力は、レポートがプロフェッショナルではない印象を与えます。

誤ってバグレポートを送信した場合は、そのレポートがまだチームリーダー (Team Leader) にレビューされていなければ、削除することができます。