Jiraでは、QAテスターが開発者が未リリースの機能を実装する方法に問題を見つけた場合、それを新しいバグとしてログに記録する必要がありますか？それとも、問題をコメントとして記録し、問題を再度開く方がよいでしょうか。
彼らが既存の問題についてのコメントとしてそれを入力した場合、タイムトラッキング機能を使用すると、その問題の実装に実際にかかった時間をより正確に把握できると思います。一方、新しいバグを作成する場合は、品質向上の目的で取り組んでいる問題の数に対して、開発者が生成しているバグの数を追跡できます。
それぞれのアプローチの長所と短所は何ですか？上で概説した両方の利点を達成する方法はありますか？
開発者としての私の好みは、テストエンジニアにコメントをしてもらい、その機能について私と話し合いを開くことです。欠陥は、リリースのペイロードにもう1つアイテムがあり、検証計画と結果のテストで対処する必要があるチケットがもう1つあります。
Jiraでは、チケットで作業した時間を追加できるため、チケットがクローズとマークされる前に複数のビルド/リリースで確認された場合でも、時間を追跡できます。
私は新しい問題を作成することに賛成です。多くの場合、根本原因が変更されたため、バグを再度開く必要があります。おそらく、開発者は新しいバージョンではもはや真実ではない多くの仮定を行ったので、元の問題の説明はもはや100％正しくありません。
（修正が明らかに間違っているためにバグを再度開く必要がある場合は、テスト戦略を修正する必要があります。）
私は17回再開されたバグを見てきました。このバグに関するコメントを印刷すると、20ページを超えるドキュメントになります。
バグを再開できることのもう1つの欠点は、ワークフローが不要になり、「再開」状態と追加の遷移が発生することです...
JCALPやJCLPなどのプラグインを使用すると、テスターは以前のバグから新しいバグを簡単に作成できます。
再開しないことの利点は、特定のビルドについてより明確にレポートできることです。
フランシス
見つかった問題ごとに新しい問題を作成し、作成された問題を元の機能に関連付けることを好みます。この場合、開発者は問題のコンテキストを失うことはなく、バグに個別に取り組む機会があります。もちろん、それはあなたがたどっているプロセスに依存しますが、通常、新機能のテスト中にQA担当者は、1つ以上のバグを見つけます。バグの優先度に応じて、機能を受け入れるか、再開することができます。さらに、この機能を見ると、それに関連するバグがたくさんあります。機能が本番環境に移行する前に、見つかったすべてのバグが修正されていない場合もあります。もちろん、見つかった問題が重大であり、新しい機能が壊れている場合、つまり機能が完全に実装されていない場合は、新しい問題を作成せずに、再度開く必要があります。