価値のある欠陥を簡単かつ効率的に提供する方法は？#
1. どのような状況で欠陥（Issue）/ 問題 / バグを提供するべきですか？#
1）機能が要件と一致しない、または技術的な問題がある場合
2）問題が自分自身やチーム内で解決できず、他の部署とのコミュニケーションやサポートが必要な場合
3）プロセスや管理の問題が露呈している場合
4）機能要件に合致しない場合は提供する必要があります。機能に誤りがある場合や一般の嗜好に合致しない場合も提供する必要があります。
2. 欠陥（Defect）/ バグの 6 つの要素#
1) タイトル：#
バグを簡潔に説明し、バグが発生した場所を示します。
問題の概要、キーワードの役割を強調し、文法エラーがないことを確保し、キーワードで簡単に検索でき、次の人に割り当てやすいようにします。
2) 再現手順：#
バグが再現するためのすべてのステップを完全かつ簡潔に説明します。
すべての関係者がこの問題を理解できるようにしますが、すべての小さなステップを含める必要はありません。
説明に基づいて問題が再現できることを確保し、前提条件がある場合は簡潔な文で説明し、関連するテストデータを提供します。
3) 実際の結果：#
実際に見た結果を説明します。スクリーンショットでは代替できません。
4) 期待される結果：#
正しいかつ標準的な結果で、実際の結果と関連付けられます。
5) 環境情報：#
システムとブラウザ（バグトラッキングシステムの提出時にはオプション）、追加の環境情報が必要な場合は、期待される結果の下に追加してください。
6) 添付ファイル：#
問題点を明確に示すために画像には明確なマーカーを使用する必要があります。必要に応じて簡単な説明を追加する必要があります。
ビデオは問題の再現プロセスをできるだけ短い時間で操作する必要があります。
ログには関連する完全なログを添付し、関係のないログは含めないでください。
3. バグの提出に注意するポイント#
バグの 6 つの要素に加えて、以下のポイントにも注意する必要があります。
"モジュール"、"所属プロジェクト"、"影響バージョン"、"タイプ / 重要度"、"システム / ブラウザ" を正確に入力してください。
"現在の割り当て" は開発責任者に割り当てることを意味します（不明な場合はテスト責任者に協力を依頼してください）。
バグのタイトルにはサブシステム名を記入する必要はありません。製品モジュールで既に選択されています。
担当者に最初の分析を行い、上司に "CC" を送信します。
バグの優先度を編集します。20％のバグは 1/2 の優先度であることを希望し、バグには軽重急がありますので、高い価値の問題を優先的に解決できます。
4. バグの調査（10 の Why）#
（What）この問題は何ですか？どのような影響がありますか？
（Why）なぜこの問題が発生するのですか？どのようなシナリオでこの問題が発生しますか？
（Where）この問題はどの段階で発見されましたか？
（Which）欠陥はどの段階で導入されましたか？
（Why）なぜこの段階で問題が導入されたのですか？
（hoW）どのようにしてこの問題を回避できますか？
（Where）この問題はどの段階で発見するべきですか？
（Why）なぜこの段階で問題が発見されなかったのですか？
（hoW）どのようにしてこの段階で問題を発見できますか？
（hoW）リスクベースのテストプロセスを改善し、このような製品リスクを抽出するためにどのようにすることができますか？