how write good bug report
なぜ良いバグレポート?
バグレポートが効果的であれば、修正される可能性が高くなります。したがって、バグの修正は、バグをどれだけ効果的に報告するかによって異なります。バグの報告はスキルに他なりません。このスキルを達成する方法を説明します。
「問題レポート(バグレポート)を作成するポイントは、バグを修正することです」– CemKaner著。 テスターがバグを正しく報告していない場合、プログラマーはおそらくこのバグを拒否し、再現不可能であると述べます。
これはテスターの道徳を傷つけ、時にはエゴも傷つける可能性があります。 (エゴを保持しないことをお勧めします。エゴは、「バグを正しく報告した」、「再現できる」、「なぜバグを拒否したのか」、「私のせいではない」などです。 、)。
学習内容:
優れたソフトウェアバグレポートの品質は何ですか?
誰でもバグレポートを書くことができます。しかし、誰もが効果的なバグレポートを作成できるわけではありません。
平均的なバグレポートと優れたバグレポートを区別できるはずです。 良いバグレポートと悪いバグレポートを区別する方法は? 非常に簡単です。次の特性と手法を適用してバグを報告してください。
特徴とテクニックが含まれます
#1)明確に指定されたバグ番号を持つ: 各バグレポートには常に一意の番号を割り当ててください。これは、次に、バグレコードを特定するのに役立ちます。自動化されたバグ報告ツールを使用している場合、この一意の番号は、バグを報告するたびに自動的に生成されます。
報告した各バグの数と簡単な説明に注意してください。
#2)再現性: バグが再現できない場合、修正されることはありません。
バグを再現する手順を明確に記載する必要があります。再現手順を想定したりスキップしたりしないでください。ステップバイステップで説明されているバグは、簡単に再現して修正できます。
#3)具体的に: 問題についてのエッセイを書かないでください。
具体的かつ的確に。問題を最小限の言葉で、しかも効果的な方法で要約するようにしてください。たとえ類似しているように見えても、複数の問題を組み合わせないでください。問題ごとに異なるレポートを作成します。
効果的なバグレポート
バグレポートは、ソフトウェアテストの重要な側面です。効果的なバグレポートは開発チームとうまく通信し、混乱や誤解を防ぎます。
良いバグレポートは 明確で簡潔 重要なポイントを見逃すことなく。明確さが欠けていると、誤解を招き、開発プロセスも遅くなります。欠陥の書き込みと報告は、テストのライフサイクルで最も重要ですが無視されている領域の1つです。
バグを報告するには、適切な記述が非常に重要です。テスターが覚えておくべき最も重要な点は 命令音を使用しない レポートで。これは士気を壊し、不健康な仕事上の関係を生み出します。示唆に富むトーンを使用します。
想定しないでください 開発者が間違いを犯したので、厳しい言葉を使うことができます。報告する前に、同じバグが報告されているかどうかを確認することも同様に重要です。
重複するバグ テストサイクルの負担です。既知のバグのリスト全体を確認してください。時々、開発者は問題を知っていて、将来のリリースのために無視したかもしれません。重複するバグを自動的に検索するBugzillaなどのツールも使用できます。ただし、重複するバグを手動で検索することをお勧めします。
バグレポートが伝達しなければならないインポート情報は 'どうやって?'そしてどこに?' レポートは、テストがどのように実行され、どこで欠陥が発生したかを正確に回答する必要があります。読者はバグを簡単に再現し、バグがどこにあるかを見つける必要があります。
覚えておいてください バグレポートを書く目的 開発者が問題を視覚化できるようにすることです。彼/彼女はバグレポートから欠陥を明確に理解する必要があります。開発者が求めているすべての関連情報を提供することを忘れないでください。
また、バグレポートは将来の使用のために保存され、必要な情報を適切に作成する必要があることに注意してください。 意味のある文章と簡単な単語を使用する あなたのバグを説明するために。レビュー担当者の時間を無駄にするような紛らわしいステートメントは使用しないでください。
各バグを個別の問題として報告してください。 1つのバグレポートに複数の問題がある場合、すべての問題が解決されない限り、レポートを閉じることはできません。
したがって、 問題を別々のバグに分割する 。これにより、各バグを個別に処理できるようになります。適切に作成されたバグレポートは、開発者が端末でバグを再現するのに役立ちます。これは、問題の診断にも役立ちます。
バグを報告する方法は?
次の簡単なバグレポートテンプレートを使用します。
これは単純なバグレポート形式です。使用しているバグレポートツールによって異なる場合があります。バグレポートを手動で作成している場合は、手動で割り当てる必要があるバグ番号など、いくつかのフィールドを具体的に記載する必要があります。
レポーター: あなたの名前とメールアドレス。
製品: このバグを見つけた製品はどれですか。
バージョン: 製品バージョン(ある場合)。
成分: これらは、製品の主要なサブモジュールです。
プラットホーム: このバグを見つけたハードウェアプラットフォームに言及してください。 「PC」、「MAC」、「HP」、「Sun」などのさまざまなプラットフォーム。
オペレーティング・システム: バグを見つけたすべてのオペレーティングシステムに言及します。 Windows、Linux、Unix、SunOS、MacOSなどのオペレーティングシステム。該当する場合は、Windows NT、Windows 2000、WindowsXPなどのさまざまなOSバージョンについても言及します。
優先度: バグはいつ修正する必要がありますか?優先度は通常、P1からP5に設定されます。 P1は「最も優先度の高いバグを修正する」として、P5は「時間が許せば修正する」として。
重大度: これは、バグの影響について説明しています。
重大度の種類:
- ブロッカー: これ以上のテスト作業は実行できません。
- クリティカル: アプリケーションのクラッシュ、データの損失。
- メジャー: 機能の大幅な喪失。
- マイナー: 機能の軽微な喪失。
- 些細なこと: いくつかのUIの機能強化。
- 機能強化: 新しい機能または既存の機能の拡張機能をリクエストします。
状態: バグ追跡システムにバグを記録すると、デフォルトでバグステータスは「新規」になります。
その後、バグは、修正済み、確認済み、再開、修正されないなどのさまざまな段階を経ます。
=> ここをクリック 詳細なバグライフサイクルの詳細については、こちらをご覧ください。
割りあてる: バグが発生した特定のモジュールを担当している開発者がわかっている場合は、その開発者の電子メールアドレスを指定できます。それ以外の場合は、マネージャーが開発者にバグを割り当てない場合はモジュール所有者にバグを割り当てるため、空白のままにします。おそらく、マネージャーのメールアドレスをCCリストに追加します。
URL: バグが発生したページのURL。
概要: バグの簡単な要約。主に60語以下。あなたの要約が問題が何であるか、そしてそれがどこにあるかを反映していることを確認してください。
説明: バグの詳細な説明。
説明フィールドには、次のフィールドを使用します。
- 手順を再現します。 明らかに、バグを再現する手順を説明してください。
- 期待される結果: 上記の手順でアプリケーションがどのように動作するか。
- 実結果: 上記の手順を実行した実際の結果、つまりバグの動作は何ですか。
これらはバグレポートの重要なステップです。バグタイプを説明するもう1つのフィールドとして「レポートタイプ」を追加することもできます。
レポートタイプは次のとおりです。
1)コーディングエラー
2)設計エラー
3)新しい提案
4)ドキュメントの問題
5)ハードウェアの問題
バグレポートの重要な機能
バグレポートの重要な機能は次のとおりです。
#1)バグ番号/ ID
バグ番号または識別番号(swb001など)を使用すると、バグの報告と参照がはるかに簡単になります。開発者は、特定のバグが修正されているかどうかを簡単に確認できます。これにより、テストと再テストのプロセス全体がよりスムーズかつ簡単になります。
#2)バグタイトル
バグタイトルは、バグレポートの他のどの部分よりも頻繁に読み取られます。バグの内容についてすべて説明する必要があります。
バグのタイトルは、読者が理解できるように十分に示唆に富むものでなければなりません。明確なバグタイトルは理解しやすく、読者はバグが以前に報告されたか修正されたかを知ることができます。
#3)優先度
バグの重大度に基づいて、優先順位を設定できます。バグには、ブロッカー、クリティカル、メジャー、マイナー、トリビアル、または提案があります。重要なものが最初に表示されるように、P1からP5までのバグの優先順位を与えることができます。
#4)プラットフォーム/環境
明確なバグレポートを作成するには、OSとブラウザの設定が必要です。これは、バグを再現する方法を伝えるための最良の方法です。
正確なプラットフォームまたは環境がないと、アプリケーションの動作が異なり、テスター側のバグが開発者側で再現されない可能性があります。したがって、バグが検出された環境について明確に言及するのが最善です。
#5)説明
バグの説明は、開発者がバグを理解するのに役立ちます。発生した問題について説明します。説明が不十分だと混乱が生じ、開発者やテスターの時間も無駄になります。
説明の効果について明確に伝える必要があります。完全な文章を使用することは常に役に立ちます。問題をまとめて崩すのではなく、各問題を個別に説明することをお勧めします。 「私は思う」や「私は信じる」などの用語は使用しないでください。
#6)再現する手順
優れたバグレポートには、再現する手順が明確に記載されている必要があります。手順には、バグの原因となるアクションを含める必要があります。一般的な発言はしないでください。従う手順を具体的にしてください。
適切に記述された手順の良い例を以下に示します。
手順:
- 製品Abc01を選択します。
- [カートに追加]をクリックします。
- カートから製品を削除するには、[削除]をクリックします。
#7)期待される実際の結果
バグの説明は、期待される結果と実際の結果がないと不完全です。テストの結果とユーザーが期待すべきことを概説する必要があります。読者は、テストの正しい結果が何であるかを知っている必要があります。明らかに、テスト中に何が起こったのか、そして何が結果だったのかを述べてください。
#8)スクリーンショット
写真は千の言葉の価値があります。障害のインスタンスのスクリーンショットを撮り、適切なキャプションを付けて欠陥を強調します。予期しないエラーメッセージを明るい赤色で強調表示します。これにより、必要な領域に注意が向けられます。
良いバグレポートを書くためのいくつかのボーナスのヒント
以下に、優れたバグレポートを作成するための追加のヒントをいくつか示します。
#1)問題をすぐに報告する
テスト中にバグを見つけた場合は、後で詳細なバグレポートを書くのを待つ必要はありません。代わりに、すぐにバグレポートを作成してください。これにより、再現性の高いバグレポートが保証されます。後でバグレポートを作成することにした場合、レポートの重要な手順を見逃す可能性が高くなります。
#2)バグレポートを作成する前にバグを3回再現する
バグは再現可能である必要があります。ステップが、あいまいさなしにバグを再現するのに十分堅牢であることを確認してください。バグが毎回再現可能でない場合でも、バグの定期的な性質に言及してバグを提出することができます。
オンライン取引のためのデータプロバイダーのウェブサイト
#3)他の同様のモジュールで同じバグの発生をテストする
開発者は、異なる類似モジュールに同じコードを使用することがあります。したがって、あるモジュールのバグが他の同様のモジュールでも発生する可能性が高くなります。見つけたバグのより深刻なバージョンを見つけようとすることもできます。
#4)良いバグの要約を書く
バグの概要は、開発者がバグの性質をすばやく分析するのに役立ちます。レポートの品質が低いと、開発とテストの時間が不必要に長くなります。バグレポートの要約とうまく通信します。バグの概要は、バグインベントリ内のバグを検索するための参照として使用されることに注意してください。
#5)[送信]ボタンを押す前にバグレポートを読んでください
バグレポートで使用されているすべての文、文言、手順を読んでください。誤解を招く可能性のあるあいまいさを生み出している文がないかどうかを確認します。明確なバグレポートを作成するには、誤解を招く単語や文を避ける必要があります。
#6)虐待的な言葉を使用しないでください
良い仕事をしてバグを見つけたのはいいことですが、開発者を批判したり、個人を攻撃したりするためにこのクレジットを使用しないでください。
結論
バグレポートが高品質のドキュメントであることは間違いありません。
これはテスター、開発者、マネージャー間の主要なコミュニケーションポイントであるため、適切なバグレポートの作成に集中し、このタスクに時間を費やしてください。管理者は、優れたバグレポートを作成することがテスターの主な責任であることをチームに認識させる必要があります。
優れたバグレポートを作成するための努力は、会社のリソースを節約するだけでなく、あなたと開発者の間に良好な関係を築くでしょう。
生産性を向上させるには、より優れたバグレポートを作成してください。
あなたはバグレポートを書くことの専門家ですか?以下のコメントセクションであなたの考えを自由に共有してください。
推奨読書
- サンプルバグレポート
- アプリケーションのバグを見つける方法は?ヒントとコツ
- ソフトウェアテストの週次ステータスレポートの書き方
- ソフトウェアテストの欠陥/バグライフサイクルとは何ですか?欠陥ライフサイクルチュートリアル
- 「無効なバグ」ラベルなしですべてのバグを解決するにはどうすればよいですか?
- Webおよび製品アプリケーションのサンプルバグレポート
- 効果的なテスト要約レポートの書き方[サンプルレポートのダウンロード]
- なぜバグレポートはすべてのテスターが学ぶべき芸術なのですか?