この記事では、私たちのルールと基準に従ってバグを適切に記録する方法を学びます。バグを理解するためには、お客様に十分な情報と質の高い記録を提供する必要があります。各セクションでルールについてより詳しく説明していますが、まずはバグレポートの要件を簡単にまとめます。

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

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

品質基準に従い、バグフォームのすべての項目に正確かつ具体的な情報を入力してください。各項目とその要件についての詳しい情報は以下に記載されています。

の場合のみ、「重要度」という追加項目が表示され、低、中、重大のいずれかを選択できます。重要度はレポートの緊急性を示し、複数の要因によって決まります。さまざまな重要度レベルについては、次の記事「機能バグ」を参照してください。

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

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

バグタイトルを書くときは、何が起きていないかではなく、何が起きているのかを説明してください。「動作しない」のような一般的な表現は避け、実際に確認された動作に焦点を当ててください。

タイトルは実際の問題を反映している必要があります。バグが特定の条件でのみ発生する場合、その条件をバグタイトルに含める必要があります。たとえば、10代であることを申告した場合にチケットを予約できないのであれば、それは関連する情報であり、タイトルに含める必要があります。

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

バグが発生するページを開き、ブラウザのURL欄からURLをコピーして、バグレポートフォームのURL欄に貼り付けてください。URLは有効なものでなければなりません。

バグは再現可能である必要があり、どのように再現するかを詳細な手順として記載する必要があります。各手順では、それぞれ1つの操作を説明してください。

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

Webサイトの場合：

1. https://test.io/ を開く

モバイルアプリの場合：

1. testNowアプリを開く
​

以降のすべての手順では、最初の手順からバグが発生するまでに行う操作を説明してください。押すボタン、開くリンク、入力する内容などを記載します。最後の手順には、バグを発生させる操作を記載する必要があります。

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

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

実際の結果はバグレポートで最も重要な項目の1つです。ここでは、問題が何であるか、そしてバグを理解するために必要なすべての詳細を説明します。

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

同様に、実際の結果をレポートのタイトルと同じ内容にしてはいけません。タイトルは問題の概要ですが、実際の結果は問題を詳しく説明するものであり、シナリオ情報、例、バグの再現手順を実行した際に得られた結果など、追加の詳細を含める必要があります。

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

期待される結果は、実際の結果に少し変更を加えたり否定語を付けたりしただけのものではありません。最後の再現手順を完了した後に何が起きるべきだったのかを説明するための、別の項目です。

バグにどのような添付ファイルを付ける必要があるか、またどのようなルールが適用されるかについては、次の記事「バグレポートの添付ファイルの要件」を参照してください。

​

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

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

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

の利用可能なデバイス一覧にないデバイスでテストしたいですか？サポートチャットからリクエストを送信してください。お客様にとって必要なデバイスであれば、一覧に追加します。

レポートを送信した後でも、選択したバグの種類を除くすべての項目を編集できます。常に確認可能な完全なバグレポートを提出し、編集機能は、小さな入力ミスを修正する場合や、レポートの品質を向上させるために表現を言い換える場合にのみ使用してください。

バグが特定の入力内容でのみ発生する場合は、実際のユーザーが使用するような用語を使い、バグレポートや添付ファイルを作成する際にランダムなキーワードを入力することは避けてください。悪い例として、顧客向け画面でアカウントを作成する際に「asdsdfkg_lajsdh」のようなユーザー名を使用することが挙げられます。このような入力はレポートをプロフェッショナルではないものに見せてしまいます。

誤ってバグレポートを提出した場合は、チームリーダーによる確認がまだ行われていない場合に限り、削除できます。