バグレポートの書き方（例文付き）
ルーカス・ベネット
⚡ スマートサマリー
バグレポートの作成は、欠陥を明確に文書化し、修正を迅速化し、ソフトウェアテストライフサイクル全体を通して開発者に再現可能な手順、深刻度、優先度、環境の詳細、およびサポート添付ファイルを提供することでソフトウェアの品質を向上させる、不可欠なテストスキルです。
バグレポートとは何ですか? なぜ適切なバグレポートが必要なのでしょうか?
バグレポートはSTLCにおける重要な文書であり、テストチームにさまざまな利点をもたらします。 tracソフトウェアテスト中に発見されたすべての欠陥、複数のバグ、エラー、その他の不一致をk個記録し、報告する。
このテスト後のドキュメントの目的は、テスト プロセス中に発生したバグのレベルについて、関係する専門家チームに情報を提供することです。
あなたの ソフトウェア開発エンジニア このタイプのレポートを使用すると、ソフトウェアに存在するすべての欠陥や問題を把握できます。また、バグの何が問題なのかを特定できるため、最適な方法で修正できます。さらに、時間と費用を節約できます。ping バグや問題点を発見する。
なぜ適切なバグの説明を気にする必要があるのでしょうか?
優れた詳細なソフトウェア バグ レポートを作成するために考慮する必要がある点は次のとおりです。
- これは、将来のリリースで同じバグが発生するのを回避するためのガイドとして機能します。
- コミュニケーション（電子メール、電話）にかかる時間を節約します。
- Less 開発者のために働きます（開発者はまさにあなたが望むことを実行します）。
- プロジェクト内のボトルネックが少なくなります。 バグはより迅速かつ効率的な方法で修正されます。
- Jira、Linear、または Azure DevOps はバグ報告をスプリント チケットやリリース パイプラインにリンクさせ、 tracQAおよびDevOpsワークフロー全体にわたる互換性。
バグレポートの書き方（バグレポートテンプレート）
バグレポートのテンプレートは、バグの種類によって異なります。tracキングシステム。あなたのテンプレートは異なる場合があります。
ただし、バグレポートを書くときは、次の共通フィールドが常に必要になります。
- バグ ID/タイトル。
- 重大度と優先度。
- 詳細説明
- 環境
- 再現する手順。
- 期待される結果。
- 実結果。
- 添付ファイル（スクリーンショット、ビデオ、テキスト）
これらのバグをすべて見てみましょう。tracキングコンポーネントを一つずつ：
1) タイトル/バグ ID:
すべてのバグには一意の識別番号が付与される必要があります。バグ報告ツールでは、新しく発生したバグに一意の番号が付けられ、バグを簡単に識別できるようにする必要があります。
例：
❌ 悪い例: 「もう一度見ると、製品が表示されません。残念ながら、表示されません。」
- ウェーブ
- 積極的な
- 冗長すぎる
解決策の導入を求めます。
✅ 良い: 「カート – カートに追加された新しいアイテムが表示されません」。
- この種のタイトルは問題を即座に特定します (CART)
- 実際の技術的な問題に焦点を当てています。
2) バグの重大度:
バグの重大度は、バグ レポートにおいて非常に重要な要素です。 アプリケーションのパフォーマンスに対する欠陥の影響について説明します。
- ブロッカー： このエラーによりアプリが失敗します。
- メジャー： 重大なエラーは、ビジネス ロジックの大きな変更を示します。
- マイナー： アプリケーションの機能には影響しませんが、期待される結果に影響を与える問題。
- 些細なこと： アプリの機能や操作には影響しません。誤字の可能性があります。
3) バグの優先度:
バグの優先度を決定するための一般的な段階は次のとおりです。
- 高： フローに影響を与えるもの、またはアプリの使用をブロックするものすべてが対象となります。
- 媒体： ユーザーエクスペリエンスに悪影響を及ぼします。
- マイナー： 他のすべてのエラー (タイプミス、アイコンの欠落、レイアウトの問題など)。
4) 環境:
バグは特定の環境で発生し、他の環境では発生しない可能性があります。 たとえば、Web サイトを実行しているときにバグが発生することがあります。 Firefox、またはアプリが動作しているときにのみ誤動作する Android デバイスと iPhone で正常に動作します。
これらのバグ レポートは、クロスブラウザーまたはクロスデバイス テストでのみ特定できます。 したがって、QA はバグを報告するときに、そのバグが XNUMX つ以上の特定の環境で観察されるべきかどうかを指定できる必要があります。
5) 要約:
しかし、バグレポートにタイトルだけを追加するだけでは目的が達成されません。タイトルだけでは不十分な場合は、レポートの簡単な要約を追加してください。
バグがいつどのように発生したかを含め、できるだけ短い言葉でまとめてください。 タイトルとバグの説明も検索で使用する必要があるため、重要なキーワードが網羅されていることを確認する必要があります。
例:
- バート： 「テストに何かを追加しようとしましたが、それを行ってもボタンをクリックしても何も表示されませんでした。」
- こだわり： 「[商品]をショップに追加しようとしたときping カートには商品を追加したのですが、特定の商品概要ページにある「追加」ボタンをクリックしても何も起こりませんでした。
6) 再現手順:
バグを報告する際は、再現手順を具体的に示すことが重要です。また、バグを引き起こす可能性のある操作についても記載してください。ここでは、一般的な表現は避けてください。
従うべき手順を具体的に示してください。
以下は、よく書かれた手順の例です。
ステップ：
- 製品 X1 を選択します。
- 「カートに追加」をクリックします。
- カートから製品を削除するには、[削除] をクリックします。
7) 期待される結果:
バグレポートでは、技術的タスク、テストケースの結果設計ごと、またはテスターの意見に従って、期待される結果を説明することが重要です。 これらはすべて、開発者が必要な情報を素早く見つけることに集中するのに役立ちます。
具体的な例を挙げますと、以下の通りです。
「送信」ボタンをクリックした後、必須フィールドが赤で強調表示されます。
8) 実際の結果:
名前が示すように、このフィールドはバグの実際の影響を説明します。 実際の結果を明確に説明することが非常に重要です。
具体的な例を挙げますと、以下の通りです。
「送信」ボタンをクリックすると、必須フィールドが緑色で強調表示されます。
9) 添付ファイル (スクリーンショットとビデオ):
バグ レポートでは、情報を視覚的に表示する必要があるときに情報を認識しやすくするために、バグ レポートにファイルを添付することをお勧めします。
具体的な例を挙げますと、以下の通りです。
- スクリーンショット： スクリーンショットを使用すると、プログラム内の間違いを簡単に説明できます。 バグが特定の注釈、円、または矢印の画像で強調表示される場合に便利です)。
- 動画： バグを言葉で説明するのは難しい場合もあるので、開発者がプログラムの不具合を修正できるよう、動画を作成するのが良いでしょう。
10) 影響を受けるバージョン:
バグが報告されるのは、影響を受けるソフトウェアのバージョンです。
11) 修正バージョン:
バグが解決されたソフトウェアのバージョンです。 したがって、バグを報告した QA は、バグが修正されたかどうかを確認するときに、正しいソフトウェア バージョンを使用します。
12） Target バージョン：
バグを修正する対象となるターゲット バージョン。 そのため、開発チームがバグの修正に取り組むときは、ほとんどの場合、特定のアプリケーション バージョンを対象とします。
13) 休業日：
これは、ソフトウェア テスト チームによってバグが解決された日付です。 バグを解決することは、ソフトウェア テストにおいて不可欠かつ不可欠な部分です。
14) ステータス:
新しいバグが作成された場合、そのステータスはオープンである必要があります。 その後、進行中、修正済み、実行中、再開などの段階を経ます。
バグレポート作成のヒント
効果的なバグ レポートを作成する際に覚えておくべき重要なヒントをいくつか紹介します。
- バグ報告を作成する際は、具体的に記述してください。無意味な情報や無関係な情報は含めないようにしてください。
- バグが検出されたらすぐに報告する必要があります。
- レポートを詳細に準備して、開発者が事実と情報を使用して問題をデバッグできるようにします。
- 検証のために、他の同様のモジュールで同じバグの発生をテストする必要があります。
- Revバグレポートを送信する前に少なくとも 1 回確認してください。
- バグ レポートには、エラーの説明が XNUMX つだけ含まれていることを確認する必要があります。
- 最後に、何か不明な点がある場合は、遠慮せずにプロジェクト マネージャーに助けを求めてください。
- JiraまたはLinearのAI支援型トリアージ機能を使用して、重要度を自動分類し、重複を提案し、レポートを適切なコンポーネント所有者にルーティングします。
バグ報告ツール
手動で実行されていたバグ報告プロセスは、現在では市場で入手可能なさまざまなバグ報告ツールを使用して実行されています。
- JIRA
- 線形
- Azure DevOps
- Zoho Bug TracKER
- Bugzilla
詳細なレビューを確認できます。 最高のバグ報告ツール。
バグレポートを作成する際の一般的な問題と解決策:
バグ レポートを作成する際の一般的な問題とその解決策をいくつか示します。
| バグレポートの例 | 問題 |
|---|---|
| 2×3を掛けると、答えはプラスになります。 | 例ではなくパターンを報告してください。 |
| これを避けるために、新しい項目を追加するとき、リストはアルファベット順に並べられます。 | 何が間違っているかを説明するだけでなく |
| 具体的な例を挙げますと、以下の通りです。 まず、ブラウザを開いてサイトのアドレスを入力する必要があります。 URL最初のフィールド「username」のスペルが間違っています。 |
常に要点を直接伝えます（決してストーリーを語らないでください）。 |
| レポート内のクライアントの名前のスペルが間違っています。 優先度: 高、重大度: 高 | 優先度と重大度を決して混同しないでください。 |
| 税金の計算式が間違っています!!?? | 大文字、赤文字、赤丸、「!」は使用しません。 |
| ホームページのUIデザインは良くないと思います。 | 自分の判断力を使うな。 |
| 不明瞭な記述の例: 本日の議論について、このページに対して必要なアクションを行ってください。 | 説明は誰にとっても理解できるものにしてください。 |
| ページの背景は青、オレンジ、または緑にする必要がありますが、黒または白にすることもできます。
Web 開発およびデザイン チームに何が必要なのかが不明瞭であるため、これは良くありません。 |
オプションを最小限に抑える |
| 税金の計算式が期待どおりに機能しないことがあります。 | 鉄則：『時々』という言葉は使わないこと。 |
バグレポートの例
以下はバグレポートの小さな例です。
[マイアカウント] 更新ボタンにマウスオーバーすると下線が表示されます。
説明: [マイ アカウント] セクションの [更新] ボタンにマウスを置くときは、下線を削除する必要があります。
リンク： http://test.com/mv-account/
ブラウザ/OS: Chrome 25.OSX ヨセミテ 10.10.2
再現する手順：
1. www.test.com にアクセスします。
2. ログイン認証情報によるログイン
3.「マイアカウント」に移動します
4. [更新] ボタンにマウスを置きます。
実結果： 下線があります。
期待される結果： 下線はありません。
ログインデータ: test@test.com / mysecretpass12
バグレポート作成時のミスを避ける必要がある
バグ レポートを作成する際に避けるべき重要な間違いをいくつか示します。
- 不満を書いてはいけません。また、個人的な感情を決して含めてはいけません。
- 投稿に多くの絵文字を詰め込みすぎると、タスクに集中したい人をイライラさせます。
- 投稿に感嘆符を多用しないでください。 作業がスピードアップするわけではありません。
- 誰も気分を害したくありません。 それはモチベーションを破壊し、問題の実現を遅らせます。
