なぜ良いバグ報告なのか

あなたのバグ報告が効果的であれば、修正される可能性も高くなります。 つまり、バグの修正は、あなたがいかに効果的にそれを報告するかにかかっています。 バグを報告することは技術に他ならず、この技術を達成する方法を説明します。

「問題報告（バグレポート）を書くことのポイントは、バグを修正してもらうことだ」 – Cem Kaner 氏。 もしテスターがバグを正しく報告していなければ、プログラマーはそのバグを再現不可能なものとして却下する可能性が高い。

これはテスターのモラルや、時にはエゴをも傷つける可能性があります。 (私は、いかなる種類のエゴも持ち続けないことをお勧めします。 私はバグを正しく報告した」、「私はそれを再現できる」、「なぜ彼/彼女はバグを拒否したのか」、「それは私のせいではない」などのエゴです）

What Are The Qualities Of A Good Software Bug Report? しかし、誰もが効果的なバグレポートを書けるわけではありません。

平均的なバグレポートと良いバグレポートを見分けられるようになる必要があります。 良いバグレポートと悪いバグレポートを見分けるにはどうしたらよいでしょうか。 それはとても簡単で、以下の特徴とテクニックを適用してバグを報告します。

Characteristics and Techniques include

#1) 明確に指定されたバグ番号を持つこと。 各バグ報告には必ず固有の番号を付けましょう。 これは、ひいてはバグ記録を識別するのに役立ちます。 自動バグ報告ツールを使用している場合、 この固有の番号はバグを報告するたびに自動的に生成されます。

報告した各バグの番号と簡単な説明をメモしてください。

あなたは、バグを再現するための手順を明確に述べなければなりません。 再現のステップを決めつけたり、省略したりしてはいけません。 ステップバイステップで記述されたバグは、再現と修正が容易です。 問題についてのエッセイを書かないこと。

具体的で要領よく。 最小限の単語で、しかも効果的な方法で問題を要約するようにしましょう。 似たような問題であっても、複数の問題を一緒にしないこと。

Effective Bug Reporting

Bug reporting はソフトウェアテストの重要な側面である。 効果的なバグレポートは、開発チームとよくコミュニケーションをとり、混乱や誤解を避けることができます。

良いバグレポートは、重要な点を見逃すことなく、明確かつ簡潔であるべきです。 明確さが欠けていると、誤解を招き、開発プロセスも遅くなります。 不具合の記述と報告は、テストのライフサイクルにおいて最も重要でありながら軽視されている分野の 1 つです。

良い文章は、バグを提出するために非常に重要です。 テスト担当者が心に留めておくべき最も重要な点は、報告で命令口調を使わないことです。 これは士気をくじき、不健康な仕事上の関係を作り出します。 示唆に富んだ口調を使いましょう。

開発者が間違いを犯したから、厳しい言葉を使ってもいいと思い込まないことです。 報告する前に、同じバグが報告されているかどうかを確認することも同様に重要です。

重複したバグは、テストサイクルの負担になります。 既知のバグの全リストを確認する。 時には、開発者が問題を知っていながら、将来のリリースのために無視している場合もあります。 重複するバグを自動的に検索する Bugzilla のようなツールも使用できます。 しかし、重複するバグを手動で検索するのが最善です。

バグ レポートが伝えなければならない輸入情報は、”どのように?” と “どこで?” です。 レポートは、テストがどのように実行されたか、不具合が正確にどこで発生したかを明確に答えなければなりません。 読者は簡単にバグを再現し、バグがどこにあるのかを見つけなければなりません。

バグレポートを書く目的は、開発者が問題を視覚化できるようにすることであることを心に留めておいてください。 彼/彼女はバグレポートから不具合を明確に理解する必要があります。

また、バグレポートは将来の使用のために保存されるものであり、必要な情報を含んでよく書かれている必要があることを心に留めておいてください。 バグを説明するには、意味のある文章と簡単な単語を使用してください。 レビュアーの時間を浪費させるような紛らわしい文は使わないでください。

それぞれのバグを個別の問題として報告してください。 1つのバグレポートに複数の問題がある場合、すべての問題が解決されない限り、バグレポートを閉じることはできません。

したがって、問題を個別のバグに分割することが最善です。 これにより、各バグを別々に処理することができます。 よく書かれたバグレポートは、開発者が自分の端末でバグを再現するのに役立ちます。

バグを報告するには？

次のシンプルなバグ報告テンプレートを使用します。 使用しているバグ報告ツールによって異なる場合があります。 手動でバグ レポートを作成する場合、バグ番号のようないくつかのフィールドを具体的に記述する必要があり、これは手動で割り当てなければなりません。

Version: どの製品でこのバグを見つけたか。

Component: 製品のバージョン（もしあれば）。

Platform: 製品の主要なサブモジュール。 このバグを発見したハードウェア プラットフォームを記載してください。 PC」、「MAC」、「HP」、「Sun」など、さまざまなプラットフォームがあります。 バグを発見したすべてのオペレーティングシステムを記載してください。 Windows、Linux、Unix、SunOS、Mac OS のようなオペレーティングシステム。 該当する場合は、Windows NT、Windows 2000、Windows XP などの異なる OS バージョンも記載してください。 バグはいつ修正されるべきでしょうか。 優先順位は一般的にP1からP5まで設定されています。 P1 は「最も優先度の高いバグを修正する」、P5 は「時間が許せば修正する」です。 バグの影響度を表します。
深刻度の種類。

• Blocker: これ以上テスト作業ができない。
• Critical: これ以上テスト作業ができない。 アプリケーションのクラッシュ、データの損失.
• Major: 機能の大きな損失。
• Minor: 軽微な機能損失
• 軽微な機能損失: いくつかのUI強化
• 強化。 新しい機能、または既存の機能強化の要求。

Status:
その後、バグは、Fixed、Verified、Reopen、Won’t Fix など、さまざまな段階に進みます。

=> 詳細なバグライフサイクルについてもっと読むにはここをクリックしてください。 バグが発生した特定のモジュールを担当する開発者がわかっている場合、その開発者の電子メールアドレスを指定できます。 そうでなければ、モジュール所有者にバグが割り当てられ、Managerが開発者にバグを割り当てますので、空欄のままにしてください。 CC リストに管理者の電子メールアドレスを追加することも可能です。 バグが発生したページの URL.

Summary: バグの簡単な要約で、主に 60 語以下です。 何が問題で、どこに問題があるのかを反映した要約であることを確認してください。

Description:

Description: バグの詳細な説明

• Reproduce steps:
• 期待される結果：バグを再現するための手順を明確に記述してください。
• 実際の結果: 上記の手順で、アプリケーションがどのように動作するはずか。

これらは、バグレポートの重要なステップです。 また、バグの種類を記述するフィールドとして、「報告タイプ」を追加することができます。

レポートの種類には次のものがあります:

1) コーディング エラー
2) デザイン エラー
3) 新しい提案
4) 文書の問題
5) ハードウェア問題

Important Features In Your Bug Report

以下に示すものは、バグ レポートの主要な機能です。

#1) バグ番号/ID

バグ番号または識別番号 (swb001 など) は、バグ報告およびバグへの参照をより簡単にします。 開発者は、特定のバグが修正されたかどうかを簡単にチェックすることができます。

#2) バグタイトル

バグタイトルは、バグレポートの他のどの部分よりもよく読まれるものです。 それはバグで来るものについてのすべてを言うべきです。

バグのタイトルは、読者がそれを理解できるように十分に示唆的であるべきです。 明確なバグのタイトルは理解を容易にし、読者はそのバグが以前に報告されたか、修正されたかを知ることができます。

#3) 優先度

バグの重大性に基づいて、それに優先度を設定することができます。 バグはBlocker、Critical、Major、Minor、Trivial、またはsuggestionになります。 P1 から P5 までのバグの優先順位をつけて、重要なものが最初に見られるようにします。

#4) プラットフォーム/環境

明確なバグレポートには、OS とブラウザの構成が必要です。 バグがどのように再現されるかを伝える最良の方法です。

正確なプラットフォームや環境がないと、アプリケーションの動作が異なり、テスター側でのバグが開発者側で再現されない可能性があるからです。 ですから、バグが検出された環境を明確に述べるのが一番です。

#5) 説明

バグの説明は、開発者がバグを理解するのに役立ちます。 それは、発生した問題を記述します。 説明の不備は混乱を招き、開発者やテスターの時間を無駄にします。

説明の効果について明確に伝えることが必要です。 完全な文章を使用することは常に有効です。 問題を全部つぶしてしまうのではなく、それぞれの問題を別々に記述するのは良い習慣です。 I think” や “I believe” のような言葉は使わないでください。

#6) 再現のためのステップ

良いバグレポートは、再現のためのステップを明確に言及すべきです。 その手順には、バグの原因となる行為が含まれていなければなりません。 一般的な記述をしてはいけません。

よく書かれた手順の良い例を以下に示します。

• 製品 Abc01 を選択します。
• カートから製品を削除するには削除をクリックします。

#7) 期待値と実績

期待値と実績がないと、バグの説明は不完全になります。 テストの結果が何であり、ユーザーが何を期待すべきかを概説する必要があります。 読者はテストの正しい結果が何であるかを知るべきです。 テスト中に何が起こったのか、そしてその結果は何だったのかを明確に述べましょう。

#8) スクリーンショット

百聞は一見にしかず。 不具合を強調するために、適切なキャプションを付けて、不具合事例のスクリーンショットを撮ってください。 予期せぬエラーメッセージは薄赤色で強調しましょう。

Some Bonus Tips To Write A Good Bug Report

Given below are some more additional tips to write a good Bug report:

#1) Report the problem immediately

If you find any bug while testing, then need not wait to write a detail bug report later.

テスト中にバグを見つけたら、バグレポートを書くのを待つ必要はない。 その代わり、すぐにバグレポートを書きましょう。 そうすることで、再現性のある良いバグレポートを確実に作成することができます。

#2) バグレポートを書く前に3回バグを再現する

あなたのバグは再現可能であるべきです。 あなたの手順が、曖昧さなくバグを再現するのに十分強固であることを確認してください。 あなたのバグが毎回再現できない場合でも、バグの周期的な性質に言及してバグを提出することができます。

#3) 他の類似モジュールで同じバグ発生をテストする

開発者は時々、異なる類似モジュールに同じコードを使用します。 そのため、あるモジュールで発生したバグが他の類似モジュールでも発生する可能性が高くなります。

#4) 良いバグサマリーを書く

バグサマリーは、開発者がバグの性質を素早く分析するのに役立ちます。 質の悪いレポートは、不必要に開発およびテスト時間を増加させます。 バグレポートのサマリーでうまくコミュニケーションをとりましょう。 バグサマリーは、バグインベントリでバグを検索するための参考資料として使用されることを心に留めておいてください。） Submitボタンを押す前にバグレポートを読む

バグレポートで使われている文章、言葉遣い、手順をすべて読んでください。 誤解を招くようなあいまいな文章がないかどうか確認してください。 誤解を招くような言葉や文章は、明確なバグレポートを作成するために避けるべきです。

#6) 乱暴な言葉を使わない

あなたが良い仕事をしてバグを見つけたのは良いことですが、この評価を開発者の批判や個人を攻撃するために使わないでください。

結論

バグレポートは高品質のドキュメントであるべきだということは間違いありません。

これはテスター、開発者、マネージャー間の主なコミュニケーションポイントなので、良いバグレポートを書くことに焦点を当て、このタスクに時間を費やしましょう。 マネージャーは、良いバグレポートを書くことがテスターの主要な責任であるという意識をチームに植え付けるべきです。