同じ問題/チケットにいくつかの欠陥を投稿することが推奨されないのはなぜですか？
これが次の概念的な質問をする場所かどうかはわかりません（Stackoverflowは間違いなくそうです）。
[〜＃〜] istqb [〜＃〜] 試験と同様に、私はこの質問を複数選択試験（単一回答）で見ました。
同じ問題/チケットでいくつかの欠陥を報告することが推奨されないのはなぜですか？
a。レポートを簡潔かつ明確にするため。
b。開発者が修正できるバグは1つだけだからです。
c。テストグループのテスターは、発見したバグの量によって評価されるためです。
d。バグ管理システムは、複数のバグのこの機能をサポートしていません。
私の唯一の意見は、aが正解だということです。
b-fix-feedback-resolved-closedはそのようなケースを回避する必要があるため、それはできません。 c-明らかに間違っています。
d-Redmine/Tracプラグインは複数のフィールドをサポートしています。
解答用紙によると、答えはbです。
誰かが理由を説明できますか？回答についての意見のあるコメントを歓迎します。
Stack Overflowにガイドラインがあると想像してみてください。1つの質問をするのではなく、同じ質問で、頭に浮かんだことは何でも、過去2週間に抱えていたすべての問題を尋ねます。賛成票と反対票はどういう意味ですか？質問のタイトルは何ですか？最良の答えを受け入れるには？質問にタグを付ける方法は？
バグ追跡システムは、バグを追跡するために行われます。バグの追跡とは、
バグが存在する可能性があることを示すレコードを、その再現方法に関する情報とともに作成し、
確かに、バグが存在し、それはバグであり、仕様によるものではないことを確認し、
バグが解決されたと主張し、
バグが解決されたことを確認します。
非常に単純なモデルでは、1と4は顧客によって、2と3は開発者によって行われます。
次のログを想像してください：
1日目[お客様]「製品詳細」ウィンドウの「削除」ボタンを押すと、アプリケーションがハングします。アプリケーションを再起動すると、製品が削除されなかったことが示されます。予想される動作は、製品を削除することです。
4日目[開発者] <問題の再現>
5日目[開発者] <リビジョン5031で解決された問題>
12日目[お客様] <チケットはクローズされました：問題は解決しました>
ログはsimple and clearです。 何がいつ行われたかを追跡する、どのバグがどのバグを解決したかなどを簡単に確認できます。たとえば、バグ追跡システムがバージョン管理に統合されている場合、特定のリビジョンを表示すると、その中でどのバグが解決されたか。
情報を見つけるは簡単です。状態は簡単に確認できます（再現されていますか？チケットが閉じられた場合、なぜですか？）。簡単ですフィルターチケット（プラグインのUIのみに関係するチケットを表示したいのですが、オープンで1週間以上前のもので、インタラクションデザイナーによって割り当てられたチケットと優先度は中または高です）。
チケットの再割り当てや、バグの担当者を最初に決定するのは簡単です。
次のログを想像してください。
1日目[お客様] [製品の詳細]ウィンドウで[削除]ボタンを押すと、アプリがハングします。また、左パネルの背景色は濃い青色ですが、紫色である必要があります。また、「製品の詳細」ウィンドウのテキストはドイツ語にうまく翻訳されていません。それは期待されていますか？最終翻訳はいつ利用可能になりますか？ところで、「製品の公開」アクションのために送信した新しいアイコンを受け取りましたか？ 「データの同期」ウィンドウには表示されません。
6日目【開発者】紫に変色しました。
7日目[開発者]はい、ドイツ語への翻訳が不完全であるのは正常です。
8日目[顧客] Okドイツ語。イタリア語はどうですか？Luciaが2日前にXMLファイルを送信しました。
9日目[開発者]大丈夫です。
10日目[顧客] Ok？不思議なことに、私のコンピューターでは、まだハングします。
11日目[開発者]いいえ、イタリア語の翻訳は問題ないと言いたかったのです。
12日目[お客様]なるほど。ありがとうございました。しかし、色に問題があります。濃い紫色に変更しましたが、メインウィンドウの上部パネルのように、淡い紫色になっているはずです。
13日目【開発者】アイコンを更新しました。
14日目[お客様]アイコンですか？どのアイコン？
15日目[開発者]更新を依頼したアイコン。
16日目[お客様]アイコンの更新を求められたことはありません。
17日目【開発者】もちろんお伺いしました。このチケットを見てください。あなたは、製品の公開アイコンを更新する必要があると書いています。私はそれをやった。
⁞
100日目[お客様]では、ログのエントリについてはどうでしょうか。
101日目[開発者]何について話しているのかわかりません。それはこのチケットにもありませんが、6199年にあります。解決したので、このチケットを閉じます。 <終了しました：問題は解決しました>
102日目[お客様]再度開いて申し訳ありませんが、問題は解決していません。ログのエントリについて話している：先週、Unicode文字が含まれているとテキストが無効になる場合があることを伝えました。覚えていますか？ <リニューアルオープン>
103日目[開発者]漠然とそのようなことを覚えていますが、このチケットの最後の3ページを検索したところ、何の痕跡も見つかりません。何が問題だったかもう一度書いていただけますか？
⁞
460日目[開発者]ネットワーク経由で暗号化されて送信されたファイルについてあなたが言ったことの痕跡を探すのに2時間費やしました。正確なリクエストが見つかるかどうかわかりません。
460日目[お客様]皆さんはもっと整理されるべきです。この問題について過去2週間に4回通知しました。なぜすべてを忘れているのですか？
⁞
このログは何ですか？それは43回解決され、43回再開されました。それは、開発者が愚かで、460日間同じ問題を解決できないことを意味しますか？ああ、いや、待って、このチケットはその間11人の開発者に割り当てられました。どうしたんだ？特定の問題を検索するにはどうすればよいですか？それは実際にはヴァネッサに割り当てられていますが、彼女の5人の同僚も、このチケットの11の問題のうち7つを懸念しています。チケットはいつ閉めるべきですか？問題の半分が解決されたときですか？それとも11のうち10
注：このようなログは存在しないと思われるかもしれません。信じてください、私は何度も見ました。
あなたの声明にコメントするだけです：
fix-feedback-resolved-closedはそのケースを回避する必要があるため、それはできません
これは、発生したすべてのバグが同時に修正されることを前提としています。次の2つの問題がある製品のv1に対してチケットが発生するシナリオを想像してみてください。
- フォームのリセットボタンは、値をクリアするのではなく、実際にフォームを送信します。
- ボタンのフォントサイズは115％であるはずですが、110％です。
どちらも実装の障害であるため、テスターが提起するのに適しています。しかし、製品の所有者が最初のサブタスクをリリースするブロッカーであると決定したとしましょう（つまり、製品が稼働する前に修正する必要があります）が、2番目のタスクは軽微な問題です（つまり、v1で修正できます）。 1リリース）。
その場合、私たちは＃2を独自のチケットに分割する以外に選択肢はありません（またはそれを忘れるリスクがあります）。これを実行できる場合、それらは互いに独立して実装、テスト、および展開できることを意味します。その場合、最初から個別の問題があることが理にかなっています。
スコープ：
この回答（および質問）は、ソースコードが仕様またはプログラマの意図に従って実行されないコード欠陥の追跡にのみ適用できるようです。
反対に、各GUIチケットは事実上「再設計」（設計の欠陥）、「改訂された仕様」、または「機能の要求」（機能が欠けている）であるため、GUIの欠陥チケットには複数の仕様が含まれることが一般的です。
欠陥追跡の重要な目的の1つは、複数の役割（プログラマー、テスター、顧客、およびマネージャー）の間で通信および調整することです。
（たとえば、ユーザーフレンドリーと比較して）コード品質の重要性が高いプロジェクトでは、欠陥追跡は複数のファセットで構成され、そのうちの1つはコード欠陥の追跡に焦点を当てます） 、拡張機能の追跡とカスタマーサポートリクエストとは別に。
コード欠陥追跡システムの目的は次のとおりです。
- independentおよびindependently reproducible欠陥、および
- 各欠陥の根本的な原因に対する最良の近似（1対1の対応）を提供するため。
その間、次の望ましい品質を最大化する必要があります。
- 欠陥の数が時間とともに増加するにつれて、効率的にスケーリングします。
- 移動標的症候群を予防します。
免責事項：この言い回しは私の個人的な経験からのものです。認定試験の目的には不十分または不正確である可能性があります。
独立した明確な追跡とは、次のことを意味します。
有効な欠陥はそれぞれ、解決済みまたは未解決のいずれかであり、あいまいさはありません。
- 理由1：管理を簡略化するため。
- 例：「未解決のチケットの数」をメトリックとして使用できるようにします。
- 理由2：実用的なアイテムに変換する
- 例：解決されない場合、責任は割り当てられたプログラマーにあります。解決されてもクローズされない場合、責任は割り当てられたテスター（検証者）にあります。
- 結果：この方法論では、部分的に解決された欠陥は、いくつかの依存する欠陥に分解する価値があります。
- 理由1：管理を簡略化するため。
独立して再現可能な欠陥は、個別に追跡する必要があります。
- 「独立して再現可能」とは、状態が異なる可能性があることを意味します。一方は修正されているように見えても、もう一方は壊れたままです。
- 理由：欠陥追跡と根本原因分析の不一致を最小限に抑えるため。
- コードの欠陥を追跡できる根本原因はそれぞれ、少なくとも1つのコード変更が必要であると考えられています。
- 2つの欠陥が独立して再現可能な場合、複数のコード変更が必要になります。
- 2つの欠陥が独立して再現可能である場合、1つのテストの合格は他のテストの合格を意味するものではないため、両方をテスト（検証）する必要があります。
- 例2：最初に2つの症状が同じ根本原因であると考えられ、したがって同じチケットに分類され、後でそれらが独立して再現可能であることが示された場合、それらを2つのチケットに分割する必要があります。
数か月後に現れる、システムを使用している誰かの視点からそれを見てください。彼らはプログラムのバグを見つけます。彼らは周りをグーグルで回っていて、彼らが抱えている問題と一致するサポートチケットがあることを確認しています。そして、ちょっと、それは閉じられています！驚くばかり！最新版で修正されています！それで、彼らは更新します...そしてバグはまだそこにありますか？これらの愚かな開発者の何が問題になっていますか？！？
実際には何もありません。バグレポートを提出した人に問題があることが判明しました。彼らは同じチケットで2つのバグを提出しました。 1つは簡単に修正でき、すぐに修正できました。もう1つは簡単ではありませんでした。 fix-feedback-resolved-closed、のようなものを使用したとしても、特に外部の観測者にとっては、何が起こっているのか明確ではない場合があります。
各バグに独自のチケットを与える方がはるかに良いです。関連しているが明らかに異なる複数のバグがある場合、ほとんどのバグ追跡システムには、バグを別のバグにリンクできる機能があります。 （そうでない場合は、単にレポートに含めることができます。「バグ＃12345も参照してください。」）