バグレポートの書き方と例

バグレポートとは何ですか? なぜ適切なバグレポートが必要なのでしょうか?

バグレポートは、テストチームにさまざまな利点を提供する STLC の重要なドキュメントです。ソフトウェアのテスト中に見つかったすべての欠陥、複数のバグ、エラー、その他の不一致を追跡し、レポートします。

このテスト後のドキュメントの目的は、テストプロセス中に発生したバグのレベルについて、関係する専門家チームに情報を提供することです。

あなたのソフトウェア開発エンジニアこのタイプのレポートを使用すると、ソフトウェアに存在するすべての欠陥や問題を認識できます。また、バグの何が問題なのかを把握できるため、最適な方法でバグを修正できます。また、バグや問題を発見できるため、時間とお金の節約にも役立ちます。

なぜ適切なバグの説明を気にする必要があるのでしょうか?

優れた詳細なソフトウェアバグレポートを作成するために考慮する必要がある点は次のとおりです。

これは、将来のリリースで同じバグが発生するのを回避するためのガイドとして機能します。
コミュニケーション（電子メール、電話）にかかる時間を節約します。
Less 開発者のために働きます（開発者はまさにあなたが望むことを実行します）。
プロジェクト内のボトルネックが少なくなります。バグはより迅速かつ効率的な方法で修正されます。

バグレポートの書き方（バグレポートテンプレート）

バグ追跡システムに依存するため、正確なバグレポートテンプレートはありません。テンプレートは異なる場合があります。

ただし、バグレポートを書くときは、次の共通フィールドが常に必要になります。

バグ ID/タイトル。
重大度と優先度。
説明
環境
再現する手順。
期待される結果。
実結果。
添付ファイル（スクリーンショット、ビデオ、テキスト）

これらのバグ追跡コンポーネントを XNUMX つずつ見てみましょう。

1) タイトル/バグ ID:

すべてのバグには一意の識別番号が付与される必要があります。バグ報告ツールでは、新しく発生したバグに一意の番号が付けられ、バグを簡単に識別できるようにする必要があります。

例：

❌ 悪い例: 「もう一度見ると、製品が表示されません。残念ながら、表示されません。」

ウェーブ
積極的な
冗長すぎる

解決策の導入を求めます。

✅ 良い: 「カート – カートに追加された新しいアイテムが表示されません」。

この種のタイトルは問題を即座に特定します (CART)
実際の技術的な問題に焦点を当てています。

2) バグの重大度:

バグの重大度は、バグレポートにおいて非常に重要な要素です。アプリケーションのパフォーマンスに対する欠陥の影響について説明します。

ブロッカー： このエラーによりアプリが失敗します。
メジャー： 重大なエラーは、ビジネスロジックの大きな変更を示します。
マイナー： アプリケーションの機能には影響しませんが、期待される結果に影響を与える問題。
些細なこと： アプリの機能や操作には影響しません。誤字の可能性があります。

3) バグの優先度:

バグの優先度を決定するための一般的な段階は次のとおりです。

高：フローに影響を与えるもの、またはアプリの使用をブロックするものすべてが対象となります。
媒体： ユーザーエクスペリエンスに悪影響を及ぼします。
マイナー： 他のすべてのエラー (タイプミス、アイコンの欠落、レイアウトの問題など)。

4) 環境:

バグは特定の環境で発生し、他の環境では発生しない可能性があります。たとえば、Web サイトを実行しているときにバグが発生することがあります。 Firefox、またはアプリが動作しているときにのみ誤動作する Android デバイスと iPhone で正常に動作します。

これらのバグレポートは、クロスブラウザーまたはクロスデバイステストでのみ特定できます。したがって、QA はバグを報告するときに、そのバグが XNUMX つ以上の特定の環境で観察されるべきかどうかを指定できる必要があります。

5) 要約:

ただし、バグレポートにタイトルだけを追加しても意味がありません。したがって、タイトルだけでは不十分な場合は、短いレポートの概要を追加できます。

バグがいつどのように発生したかを含め、できるだけ短い言葉でまとめてください。タイトルとバグの説明も検索で使用する必要があるため、重要なキーワードが網羅されていることを確認する必要があります。

例:

バート： 「テストに何かを追加しようとしましたが、それを行ってもボタンをクリックしても何も表示されませんでした。」
こだわり： 「[製品] をショッピングカートに追加しようとしましたが、特定の製品概要 Web ページで [追加] ボタンをクリックしても何も起こりませんでした。」

6) 再現手順:

バグを報告するときは、バグを再現する手順を指定することが重要です。バグの原因となる可能性のあるアクションも含める必要があります。ここでは、一般的な発言はしないでください。

従うべき手順を具体的に示してください。

以下は、よく書かれた手順の例です。

ステップ：

製品 X1 を選択します。
「カートに追加」をクリックします。
カートから製品を削除するには、[削除] をクリックします。

7) 期待される結果:

バグレポートでは、技術的タスク、テストケースの結果設計ごと、またはテスターの意見に従って、期待される結果を説明することが重要です。これらはすべて、開発者が必要な情報を素早く見つけることに集中するのに役立ちます。

例：

「送信」ボタンをクリックした後、必須フィールドが赤で強調表示されます。

8) 実際の結果:

名前が示すように、このフィールドはバグの実際の影響を説明します。実際の結果を明確に説明することが非常に重要です。

例：

「送信」ボタンをクリックすると、必須フィールドが緑色で強調表示されます。

9) 添付ファイル (スクリーンショットとビデオ):

バグレポートでは、情報を視覚的に表示する必要があるときに情報を認識しやすくするために、バグレポートにファイルを添付することをお勧めします。

例：

スクリーンショット： スクリーンショットを使用すると、プログラム内の間違いを簡単に説明できます。バグが特定の注釈、円、または矢印の画像で強調表示される場合に便利です)。
動画： 場合によっては、バグを言葉で説明するのが難しい場合があるため、開発者がプログラムの欠陥を修正できるようにビデオを作成することをお勧めします)。

10) 影響を受けるバージョン:

バグが報告されるのは、影響を受けるソフトウェアのバージョンです。

11) 修正バージョン:

バグが解決されたソフトウェアのバージョンです。したがって、バグを報告した QA は、バグが修正されたかどうかを確認するときに、正しいソフトウェアバージョンを使用します。

12） Target バージョン：

バグを修正する対象となるターゲットバージョン。そのため、開発チームがバグの修正に取り組むときは、ほとんどの場合、特定のアプリケーションバージョンを対象とします。

13) 休業日：

これは、ソフトウェアテストチームによってバグが解決された日付です。バグを解決することは、ソフトウェアテストにおいて不可欠かつ不可欠な部分です。

14) ステータス:

新しいバグが作成された場合、そのステータスはオープンである必要があります。その後、進行中、修正済み、実行中、再開などの段階を経ます。

バグレポート作成のヒント

効果的なバグレポートを作成する際に覚えておくべき重要なヒントをいくつか紹介します。

バグレポートを作成するときは具体的にしてください。無駄な事実や無関係な事実を含めないように注意してください。
バグが検出されたらすぐに報告する必要があります。
レポートを詳細に準備して、開発者が事実と情報を使用して問題をデバッグできるようにします。
検証のために、他の同様のモジュールで同じバグの発生をテストする必要があります。
Revバグレポートを送信する前に少なくとも 1 回確認してください。
バグレポートには、エラーの説明が XNUMX つだけ含まれていることを確認する必要があります。
最後に、何か不明な点がある場合は、遠慮せずにプロジェクトマネージャーに助けを求めてください。

バグ報告ツール

手動で実行されていたバグ報告プロセスは、現在では市場で入手可能なさまざまなバグ報告ツールを使用して実行されています。

ジラ
Zohoバグトラッカー
Bugzillaの

詳細なレビューを確認できます。最高のバグ報告ツール。

バグレポートを作成する際の一般的な問題と解決策:

バグレポートを作成する際の一般的な問題とその解決策をいくつか示します。

バグレポートの例	問題
2×3を掛けると、答えはプラスになります。	例ではなくパターンを報告してください。
これを避けるために、新しい項目を追加するとき、リストはアルファベット順に並べられます。	何が問題なのかを説明するだけではない
例：そのためには、ブラウザを開いてサイトの URL を入力する必要があります。最初のフィールド「ユーザー名」のスペルが間違っていることがわかります。	常に要点を直接伝えます（決してストーリーを語らないでください）。
レポート内のクライアントの名前のスペルが間違っています。優先度: 高、重大度: 高	優先度と重大度を決して混同しないでください。
税金の計算式が間違っています!!??	大文字、赤文字、赤丸、「!」は使用しません。
ホームページのウルのデザインは良くないと思います。	自分の判断で判断しないでください。
不明瞭な記述の例: 本日の議論について、このページに対して必要なアクションを行ってください。	説明は誰にとっても理解できるものにしてください。
ページの背景は青、オレンジ、または緑にする必要がありますが、黒または白にすることもできます。 Web 開発およびデザインチームに何が必要なのかが不明瞭であるため、これは良くありません。	オプションを最小限に抑える
税金の計算式が期待どおりに機能しないことがあります。	黄金律: 「時々」という言葉は使用しないでください。

バグレポートの例

以下はバグレポートの小さな例です。

[マイアカウント] 更新ボタンにマウスオーバーすると下線が表示されます。

説明: [マイアカウント] セクションの [更新] ボタンにマウスを置くときは、下線を削除する必要があります。

リンク： http://test.com/mv-account/

ブラウザ/OS: Chrome 25.OSX ヨセミテ 10.10.2

再現する手順：

1. www.test.com にアクセスします。

2. ログイン認証情報によるログイン

3.「マイアカウント」に移動します

4. [更新] ボタンにマウスを置きます。

実結果： 下線があります。

期待される結果： 下線はありません。

ログインデータ: test@test.com / mysecretpass12

バグレポート作成時のミスを避ける必要がある

バグレポートを作成する際に避けるべき重要な間違いをいくつか示します。

不満については書かないでください。また、個人的な感情を含めないでください。
投稿に多くの絵文字を詰め込みすぎると、タスクに集中したい人をイライラさせます。
投稿に感嘆符を多用しないでください。作業がスピードアップするわけではありません。
誰も気分を害したくありません。それはモチベーションを破壊し、問題の実現を遅らせます。

よろしければ：