各会社には、バグトラッカーにエントリを記録するための独自のルールがあります。これは、会社のポリシー、開発技術、使用されるバグトラッカー、プロジェクトのタイプなどに依存します。 しかし、いずれにしても、良いバグレポートには特定の特徴があります。
つまり、優れたバグレポートを使用すると、次のことが可能になります。
1.問題を再現します（常に可能とは限りませんが、努力する必要があります）。
2.問題とその重要性を理解します。
良いバグレポートを書く方法は？
最初に準備する必要があります。 バグを見つけた場合は、すぐにバグトラッカーにアクセスして「何も機能しない！」と書いてはいけません。 エラーを再現します。 再現？ 素晴らしい。 プレイできない？ 意味、あなたは何かを考慮しなかった。 あなたがしたことを覚えておいてください。
もう一度プレイしましたか？ やった！ 次に、再生するステップ数を最小限に抑え、余分なものがないことを確認します。
入力データを使用する場合は、入力データが多すぎないことを確認してください（この巨大なテキスト全体が実際にはエディターからドロップし、1文字だけではありませんか？）。
問題の原因となるデータやアクションの種類を理解したら、その本質を簡潔に述べてください-バグレポートの見出しを考えてください。 タイトルの許す限り詳細に、具体的に問題を説明してください。
悪いタイトルの例：「クリップボードからテキストを貼り付けるとすべてがハングします」
「良い」見出しの例：「Ctrl + Vを使用してクリップボードから文字Nを含むテキストを貼り付けると、エディターがフリーズします」
アレナリー ：あなたはまだ「何？ どこ？ いつ？」 ほとんどの場合、適切なタイトル/詳細な説明を書くと役立ちます。たとえば、
内容：不正なデータ計算
場所：NNNページ
とき：aを入力した後、Yフィールドは負の値です。
「リンクをクリックする」、「ボタンをクリックする」などのフレーズを書かないようにしてください。 手順のタイトルと説明は、問題を修正する人のためのアクションのガイドです。したがって、「リンクをクリックする」、「ボタンをクリックする」と定式化することをお勧めします。
バグトラッカーを開き、バグレポートフォームへの記入を開始します。
タイトルを記録します。
一部のバグトラッカーでは、「詳細な説明」フィールドと「再生手順」フィールドが異なりますが、そうでないものもあります。
「 詳細説明 」フィールドがある場合は、問題をより詳細に説明します。タイトルで省略しなければならなかった詳細を指定します。 問題の原因がわかっている場合（計算に古い式が使用されている、値が考慮されていないなど）-ここにもすべてを書いてください。 わからない場合は、推測しないでください。
エラーレコードフォームに個別のフィールドAffect version（問題が発生する製品のバージョン）がない場合は、ここでバージョンを指定します。
「 再生手順 」-バグレポートに入力するメインフィールド。
特定したステップを書き留めます。 すでに述べたように、問題を再現するには手順が必要で十分なはずです。 過剰に書かないでください。 お見逃しなく:)
手順を説明した後、結果を必ず書いてください-何が起こったのか。
次に、必要に応じて、期待される結果についても説明します。 もちろん、「エディターはクラッシュしません」と書くべきではありませんが、たとえば、計算結果が期待した結果に合わない場合は、これを示す必要があります。
したがって、再生の手順の説明は次のようになります。
プレイ手順：
1.開く...
2.クリック
3.フィールドに値N1を入力します...
4.フィールドに値N2を入力します...
4.「計算」ボタンをクリックします。
結果：
結果フィールドにV1が表示されます。
期待される結果：
結果フィールドにV2が表示されます。
ソースファイル、データ、ダンプなどが必要な場合は、すぐに添付してください。 もちろん、ファイルにはエラーを再現するために必要な情報のみを含める必要があります。 不要なものをすべてクリーンアップします。
視覚的な表示に問題がある場合は、スクリーンショットが必要です-ステップを再現せずにエラーを理解できます。 Khizhnyak ：スクリーンショットでは、エラーのある場所を示す方が適切です。 矢印または対照的な色のストライプ。 スクリーンショットの「読み取り」を大幅に加速します。
ただし、各バグレポートにスクリーンショットを挿入する必要はまったくありません。不要なエンティティを作成しないでください。 問題の再現に役立たない場合は、時間を無駄にしないでください。
ちなみに、ビデオの再生エラーについては、問題が本当にあることを確認するのに役立ちますが、単に再現するのは困難です。 しかし、どのくらいの頻度で事前に画面を録画しますか？ :)
残りのフィールドについて。
重大度、優先度。
これらのフィールドの存在とこれらのフィールドの値は、バグトラッカーごとに異なります。
重大度とは、テスターの観点から見たバグの重大度です。機能、テキストのタイプミス、小さな問題、重大な問題、製品のクラッシュ、ブロッキングの問題などです。
優先度-問題を修正する優先度。
両方のフィールドがある場合、テスターは、原則として、重大度と優先度のみを設定します-シニアテスター/シニアプログラマ/マネージャーまたはこの問題に責任を持つ他の人。
フィールドが1つしかない場合は、設定します。
「バグを報告する優先順位は何ですか？」この質問に対する単一の答えはありません。すべて特定のケースに依存します。 しかし、夢中にならないようにし、すべてのバグを高い優先度または重要な優先度で並べないでください。プロジェクトに対する重要度を実際に評価してください。
環境 -すべてのバグ追跡システムにあります。 これは、問題が顕在化するハードウェアおよびソフトウェア環境です。
オペレーティングシステムのバージョン、サービスパックの存在、ビット深度を示します。
プロジェクトがいくつかのコンポーネントに依存している場合-それらの可用性とバージョンが必要です！ .NET、JRE / JDKおよびその他のSDK。
通訳言語？ 通訳バージョン-必須！
Webプロジェクトの場合-これはプロジェクトに影響する場合、ブラウザ、インストールされたプラグイン。 あるブラウザーで機能しない場合は、残りのブラウザーで機能するかどうかを確認します。
どのバージョンを修正するか、誰に割り当てるか-社内のポリシーによって異なります。 何を置くべきか分からないのですか？ 同僚に聞いてください。
この記事には、コメントからの正しいコメントが補足されています。