回答:
私の古い会社では、これらのステータスを使用して、問題が「再開」に進んだ回数を追跡し、デベロッパーの「悪さ」を確認しました。彼らは、ワークアイテムが「再開」された回数とプログラマーとしてのあなたの価値との間に相関関係があると考えました。
私はもうそこで働きません。
多くの場合、バグの存続期間は次のとおりです。
すなわち。
誰かがバグを見つけてトラッカーで開きます。開発者は、問題を理解した上で、できる限り修正します。テスターは、修正が機能したことを確認するために再テストし、修正が機能しなかったことを確認できる場合は再度開きます。修正が確認されたら、バグはクローズされます。
もう1つのシナリオは、他の場所で修正を行うとリグレッションが発生し、バグを修正し直す必要があるというものです。したがって、それは再び開かれます。
また、問題が解決されたと考えられた後も問題が引き続き発生するため、問題をより注意深く、またはより早く注意を払う必要があることをより明確にすることもできます。
ここでの使用方法：
新しいタスク： プロジェクトの開始時に作成され、実行する必要のあるすべての作業を示します。誰かがそれをコード化するまで開いていて、それが解決されます。何かが実装されなかった場合、または機能が変更され、開発者が戻ってそれにかなりの時間を費やさなければならない場合にのみ、再オープンされます。
バグ/欠陥： QAまたは他の開発者が作業中の製品全体をチェックすることでオープンしました。バグが割り当てられている場合は、バグを修正してから解決し、テストに戻ります。QAが修正されていないと感じた場合は、QAを再度開き、必要なその他の情報を添付します。解決/再開のサイクルは、バグが修正されたことがQAで確認されるまで続き、チケットを閉じます。
したがって、基本的にはReopenを使用して、チケットはすでに見られており、誰かが解決したと感じた作業を行ったと言いますが、そうではありませんでした。
それは基本的に一貫性のあるものです。バグ（または一般的な問題）は、ゼロから作成されたものであれば「オープン」です。前の処理が実行された後に作成された場合、「再開」されます。
開発者（または問題を処理する人）にとっては、違いはありません。保証が提起され、処理する必要があります。
ただし、明確な「再開」ステータスは、いくつかのシナリオで引き続き役立ちます。
まず、品質保証プロセスが機能しているかどうかを追跡する方法として使用できます。QAがすべてを正しく行っていれば、修正後にバグが発生することはありません。したがって、バグが「再開」状態に設定された回数は、QAが正しく機能しなかった回数と言えます。もちろん、これは確立された優れたQAプロセスがあり、ユーザーがプロセスに積極的に参加し、問題をいつ「開く」か、いつ「再開」するかを知っていることを意味します。
別の用途は、バグが再び発生したときに、別の問題を解決する必要はありませんが、既存の問題に情報を追加することができます（したがって、問題の履歴、アップロードされた追加ファイル、以前のコメント、など）と表示されますが、「やあ、これは再び起こりました）。