タイトル、URL、手順、実際の結果、期待される結果、添付ファイル、および使用環境は、バグレポート機能の項目です。この記事では、バグレポートフォームのすべての項目で最もよくある間違いと、それらを避ける方法について説明します。それでは始めましょう！

バグのタイトルを作成する際は、レポートを開かなくても、読者が問題の概要を理解できるようにしてください。良いタイトルには、バグを理解し、他のバグレポートと区別するために必要な情報が含まれています。必要な情報には、何が起きたのか、どこでバグが発生したのか、そして、いつ、どのように、またはどのような条件で発生したのかが含まれます。

悪い例: Become a Testerボタンが動作しない。

正しい例: ユーザーがナビゲーション内の「Become A Tester」ボタンをクリックしても反応がない。

悪い例: Data Privacyリンクを開くと404ページが表示される。

正しい例: ユーザーがフッター内の「Data Privacy」リンクをクリックすると、Error 404ページが表示される。

URL欄にURLを追加する際は、バグが発生する場所のURLを追加していることを確認してください。そのため、必ずバグが発生するページを開き、そのURLをコピーしてURL欄に貼り付けてください。

手順で最もよくある間違いは、最初の手順にテスト対象のWebサイトのURLが含まれていないことです。Webサイトをテストする場合は、最初の手順に必ずURLを追加してください。また、その他によくある間違いとして、一部の手順が不足していることや、関係のない手順が記載されていることがあります。

例を見てみましょう。

このように、手順は常に正確かつ詳細に記載し、バグが発生するまでに実行した操作のみを説明する必要があります。また、手順をよりわかりやすくするためにMarkdownを使用することもできます。

実際の結果を記載する際は、バグを詳細に説明する必要があります。バグが何であるか、そしていつ発生するかを正確に記載してください。また、エラーメッセージなど、その他の関連情報もすべて含める必要があります。

悪い例: Become a Testerボタンが実装された機能を表示しない。

正しい例: Test IOのWebサイトを開き、ナビゲーション内の「Become a Tester」ボタンをクリックしても反応はありません。ユーザーは同じページに留まり、リダイレクトも発生しません。

結果の説明では、常に詳細に記載し、できる限り多くの関連情報を提供してください。これにより、お客様の理解が深まり、バグレポートが受理される可能性が大きく高まります。

期待される結果では、バグが発生しない場合に期待される動作を正確に記載する必要があります。また、この項目でも詳細に記載してください。さらに、期待される結果は、実際の結果の単なる反対であってはならないことに注意してください。

悪い例: Become a Testerボタンをクリックすると新しいページへリダイレクトされる。

正しい例: ユーザーがナビゲーション内の「Become a Tester」ボタンをクリックすると、Test IOプラットフォームでテスターになる方法に関する情報が記載された新しいページが開く必要があります。

前述のとおり、期待される結果は常に詳細かつ正確に記載してください。期待する動作を具体的に記載してください。

添付ファイルでよくある間違いについては、Academy記事「添付ファイルでよくある間違い」を参照してください。

スクリーンキャストまたはスクリーンショットと一致するデバイスおよびブラウザーを必ず選択してください。バグレポートを送信した後でも、チームリーダーがレビューする前であれば、この情報を変更できます。誤ったデバイスまたはブラウザーが選択されている場合、レポートは却下されます。