同じ問題/チケットに複数の欠陥を投稿することが推奨されないのはなぜですか？

これが次の概念的な質問をする場所であるかどうかはわかりません（Stackoverflowは間違いなくそうではありません）。

この質問は、ISTQB試験に似た多肢選択試験（単一回答）で見ました。

同じ問題/チケットでいくつかの欠陥を報告することが推奨されないのはなぜですか？

a。レポートを簡潔かつ明確にするため。

b。開発者が修正できるバグは1つだけだからです。

c。テストグループのテスターは、発見したバグの量によって評価されるためです。

d。バグ管理システムは、複数のバグのこの機能をサポートしていません。

私の唯一の意見は、それaが正しい答えだということです。

b-fix-feedback-resolved-closedがそのケースを回避するはずなので、それはできません。 c-明らかに間違っています。

d -Redmine / Tracプラグインは複数のフィールドをサポートします。

解答用紙によると、答えはbです。

誰かが理由を説明できますか？回答に関する意見を含むコメントを歓迎します。

Stack Overflowにガイドラインがあるかどうかを想像してみてください。1つの質問をする代わりに、同じ質問で頭に浮かぶものは何でも、過去2週間に発生したすべての問題を尋ねます。upvoteとdownvoteはどういう意味ですか？質問のタイトルは何ですか？ベストアンサーを受け入れる方法は？質問にタグを付ける方法は？

バグ追跡システムは...バグを追跡します。バグの追跡とは：

1. バグが存在する可能性があるという記録を作成し、それを再現する方法についての情報とともに、

2. 実際に、バグが存在し、設計上の問題ではなくバグであることを確認し、

3. バグが解決されたと断言し、

4. バグが解決されたことを確認します。

非常に単純なモデルでは、1と4は顧客によって、2と3は開発者によって行われます。

次のログを想像してください：

• 1日目[お客様] [製品の詳細]ウィンドウで[削除]ボタンを押すと、アプリケーションがハングします。アプリケーションを再起動すると、製品が削除されなかったことが示されます。期待される動作は、製品を削除することです。

• 4日目[開発者] <問題の再現>

• 5日目[開発者] <リビジョン5031で解決された問題>

• 12日目[お客様] <チケットのクローズ：問題は解決しました>

ログは単純明快です。何が行われ、いつ、どのリビジョンがどのバグを解決したかなどを簡単に追跡できます。たとえば、バグ追跡システムがバージョン管理に統合されている場合、特定のリビジョンを表示すると、そのバグが解決されたバグを確認できます。

情報を見つけるのは簡単です。その状態は簡単に確認できます（複製されていますか？チケットがクローズされた場合、なぜですか？）。チケットをフィルタリングするのは簡単です（プラグインのUIのみに関係するチケットを表示したいのですが、1週間以上経過しており、インタラクションデザイナーによって割り当てられ、優先度が中または高のチケットのみが必要です）。

チケットを再割り当てしたり、バグの責任者を決定するのは簡単です。

次のログを想像してください。

• 1日目[お客様] [製品の詳細]ウィンドウで[削除]ボタンを押すと、アプリがハングします。また、左パネルの背景色は濃い青ですが、紫でなければなりません。また、「製品の詳細」ウィンドウのテキストはドイツ語にうまく翻訳されていません。期待されていますか？最終的な翻訳が利用可能になるのはいつですか？ところで、「製品の公開」アクションのために送信した新しいアイコンを受け取りましたか？[データの同期]ウィンドウに表示されません。

• 6日目[開発者]色を紫色に変更しました。

• 7日目[開発者]はい、ドイツ語への翻訳が不完全であるのは普通です。

• 8日目[お客様]ドイツ語でOK。イタリアはどうですか？Luciaは2日前にXMLファイルを送信しました。

• 9日目[開発者]大丈夫です。

• 10日目[お客様] [削除]ボタンでよろしいですか？奇妙なことに、私のコンピューターでは、まだハングしています。

• 11日目[開発者]いいえ、イタリア語の翻訳は問題ないと言いたかったです。

• 12日目[お客様]なるほど。ありがとうございました。しかし、色に問題があります。これを濃い紫色に変更しましたが、メインウィンドウのトップパネルのように薄い紫色になっているはずです。

• 13日目[開発者]アイコンを更新しました。

• 14日目[お客様]アイコンは？どのアイコン？

• 15日目[開発者]あなたが更新するように私に頼んだアイコン。

• 16日目[お客様]アイコンの更新をお願いしたことはありません。

• 17日目[開発者]もちろんあなたは尋ねました。このチケットをご覧ください。製品の公開アイコンを更新する必要があると書きました。やった

  ⁞

• 100日目[お客様]では、ログのエントリはどうですか？

• 101日目[開発者]あなたが何について話しているのかわかりません。それはこのチケットにもありませんが、6199にあります。<チケットのクローズ：問題は解決しました>

• 102日目[お客様]再開して申し訳ありませんが、問題は解決しません。ログのエントリについて話しています。先週、テキストにユニコード文字が含まれていると、テキストが無効になることがあるとお伝えしました。覚えていますか？<チケットの再開>

• 103日目[開発者]そのようなことを漠然と覚えていますが、このチケットの最後の3ページを検索した後、痕跡を見つけることができません。問題をもう一度書いていただけますか？

  ⁞

• 460日目[開発者] 2時間かけて、ネットワーク経由で暗号化されて送信されたファイルについてあなたが言ったことの痕跡を探しました。正確なリクエストを見つけることができるかどうかわかりません。

• 460日目[お客様]あなた方は本当にもっと組織化されるべきです。過去2週間、この問題について4回通知しました。なぜすべてを忘れているのですか？

  ⁞

このログは何についてですか？43回解決され、43回再開されました。開発者が愚かすぎて、同じ問題を460日間解決できないということですか？ああ、いや、このチケットは11人の開発者に割り当てられました。どうしたんだ？特定の問題を検索する方法は？実際にはヴァネッサに割り当てられていますが、彼女の5人の同僚も、このチケットの11の問題のうち7つに関心を持っています。チケットはいつ閉じる必要がありますか？問題の半分が解決されたときですか？それとも11個のうち10個？

注：このようなログは存在しないと思われるかもしれません。私を信じて、私は複数回見たことがあります。

あなたの声明にコメントするだけです：

fix-feedback-resolved-closedがそのケースを回避するはずなので、それはできません

これは、発生したすべてのバグが同時に修正されることを前提としています。製品のv1に対してチケットが発生するシナリオを想像してください。2つの問題があります。

1. フォームリセットボタンは、値をクリアするのではなく、実際にフォームを送信します
2. ボタンのフォントサイズは115％であるはずですが、110％です。

どちらも実装の障害であるため、どちらもテスターが上げるのに適しています。しかし、最初のサブタスクはリリースするブロッカーであるとプロダクトオーナーが決定したとしましょう（つまり、製品が公開される前に修正する必要があります）が、2番目のタスクはマイナーな問題です（つまり、v1で修正できます）。 1リリース）。

その場合、＃2を独自のチケットに分割する以外に選択肢はありません（または、忘れてしまうリスクがあります）。これを行うことができれば、互いに独立して実装、テスト、展開できることを意味します。その場合、最初から個々の問題を抱えることが理にかなっています。

範囲：

この回答（および質問）は、ソースコードが仕様またはプログラマの意図に従って実行されないコード障害の追跡にのみ適用されるようです。

それどころか、各GUIチケットは事実上「再設計」（設計欠陥）、「改訂された仕様」、または「機能要求」（機能の欠落）であるため、GUI欠陥チケットには複数の仕様が含まれるのが一般的です。

欠陥追跡の重要な目的の1つは、複数の役割（プログラマー、テスター、顧客、およびマネージャー）間の通信と調整です。

コードの品質が非常に重要なプロジェクトでは（たとえば、使いやすさと比較して）、欠陥追跡は複数のファセットで構成され、その1つは、機能強化や顧客サポートリクエストの追跡とは別に、コード欠陥の追跡に焦点を当てます。

コード欠陥追跡システムの目的は次のとおりです。

• 独立して再現可能な欠陥の独立した明確な追跡を可能にし、
• 各欠陥の根本原因に最適な近似（1対1対応）を提供する。

その間、次の望ましい品質を最大化する必要があります。

• 欠陥の数が時間とともに増加するにつれて、効率的にスケーリングします。
• 移動標的症候群を防ぎます。

免責事項：この言い換えは私の個人的な経験からです。認定試験の目的には不十分または不正確かもしれません。

独立した明確な追跡とは、次のことを意味します。

1. それぞれの有効な欠陥のいずれかすることができます解決したり解決しない、曖昧さのありません。

   • 理由1：管理を簡素化するため、
     • 例：メトリックとして「未解決チケットの数」の使用を有効にします。
   • 理由2：アクション可能なアイテムに変換する
     • 例：解決しない場合、責任は割り当てられたプログラマーにあります。解決されたが閉じられていない場合、責任は割り当てられたテスター（検証者）にあります。
   • 結果：この方法論では、部分的に解決された欠陥は、いくつかの依存欠陥に分割するに値します。

2. 独立して再現可能な欠陥は、個別に追跡する必要があります。

   • 「独立して再現可能」とは、異なる状態を持つことができることを意味します。1つは修正されたように見えますが、もう1つは壊れたままです。
   • 理由：欠陥追跡と根本原因分析の間の不一致を最小限に抑えるため。
     • コードの欠陥を追跡できる各根本原因には、少なくとも1つのコード変更が必要であると考えられています。
     • 2つの欠陥が独立して再現可能な場合、複数のコード変更が必要になります。
     • 2つの欠陥が独立して再現可能である場合、1つのテストに合格しても他のテストに合格することを意味しないため、両方をテスト（検証）する必要があります。
   • 例2：最初に2つの症状の根本原因が同じであると考えられていたために同じチケットに分類され、それらが後で独立して再現可能であることが示された場合、それらを2つのチケットに分割する必要があります。

システムを使用している他の誰かの観点から見て、数か月後に表示されます。プログラムのバグを見つけます。彼らは周りをグーグルで調べて、抱えている問題に一致するサポートチケットがあることを確認します。そしてちょっと、閉まっています！驚くばかり！最新バージョンで修正されました！だから、彼らは更新します...そしてバグはまだそこにありますか？これらの愚かな開発者の何が問題なのですか？！？

実際には何もありません。バグレポートを提出した人に何か問題があることがわかりました。同じチケットで2つのバグを提出しました。1つは簡単に修正でき、すぐに修正されましたが、もう1つはそうではありませんでした。fix-feedback-resolved-closedのようなものを使用しても、特に外部のオブザーバーにとっては、何が起こっているのかがはっきりしないことがあります。

各バグに独自のチケットを与える方がはるかに優れています。関連しているが明らかに異なる複数のバグがある場合、ほとんどのバグ追跡システムには、あるバグを別のバグにリンクできる機能があります。（そうでない場合は、レポートに入れることができます。「バグ＃12345も参照してください。」）