自分自身を修正したように見えるバグにどのように対処しますか？
私は内部システムのWebアプリケーション開発者です。ユーザーがバグがあると報告しています。
バグは、一部の単語が表示されないことでした。レポートには、バグを明確に示す画面キャプチャが含まれています。しかし、レポートはほぼ1か月前のものであり、バグは実稼働環境では再現できません。
クライアントとユーザーにどのように返信すればよいですか？
開発環境をバグが通知されたバージョンに戻し、バグが存在することを確認します。
存在する場合は、バグを調査して、現在のバージョンにバグがないことを確認できます。次に、無関係な変更によって修正されたというコメントでバグレポートを閉じます。必要に応じて、回帰テストを追加します。
そのバージョンでバグを再現できない場合は、他の多くの質問で説明されている戦略が役に立ちます（最初のリストについてはThomasに感謝します）。
私は、バグを再現するためにできることはすべてできるが、できないことを真に実行したと仮定します。
このような場合、多くの場合、実行中の作業をログに記録できなかったアプリケーションの領域の周りにコードを追加するのが最善です。そうすれば、再び発生した場合に作業用のデータが増えることを期待しています。現在必要な情報のうち、現在入手できないものについて考えます。たとえば、特定の入力パラメータのセットが送信されたときにのみ発生するため、プロセスが実行されるたびにそれらを記録します。上司に確認してください。ただし、これを行う前に、バグの重要性と発生頻度によっては、上司がこれを行うのに時間をかけたくない場合があります。
次に、バグを報告した人に行き（バグ追跡アプリケーションでこれを行うことができます。直接行く必要はありません）、バグを再現することはできなかったが、追加のバグを追加したと言います。バグが再発した場合のプロセスの動作の詳細を取得するためのロギング。次に、バグを閉じます。
追加のロギングを実行できない場合。バグが再現できなかったことと、バグが再び発生した場合に、これを再現して必要な情報を伝える必要があることを報告してください。エラーが発生したときに入力パラメーターを正確に入力するように依頼することがよくあります。エラーのスクリーンショットを用意するだけで問題は解決しますが、エラーが発生したときにユーザーが実行した手順と使用しようとした情報を正確に把握することは、さらに役立ちます。したがって、基本的にあなたは彼らに責任を取り戻し、再び発生した場合に彼らがエラーを報告するときに、より多くの情報を提供します。
バグトラッカーで、試行した手順を必ず説明してください。これにより、バグが再度発生した場合に、バグを処理する担当者が以前に行ったことの背景がわかるようになります。
再現できないバッグが最悪！当面の間は修正されているか、まだ存在しているが散発的であるか、再現手順が十分に指定されていない可能性があります。バグのリスクの高さ、およびバグの調査でどれだけ拡張するかについて判断を下さなければなりません。オンラインのレシピマネージャー、または核ミサイルのステアリング制御ソフトウェアを作成していますか？
影響の少ないバグで、変更が行われたことがわかっている場合couldにより、バグが意図せずに修正されたため、再現できないという注記を付けてバグを閉じることは許容される場合があります。そして、あなたはそれが修正されたと思います。
もっと気になる場合は、まずバグの原因について理論を立て、変更ログとソース履歴を調べて、修正箇所を特定できるかどうかを確認します。
さらに深刻なバグについては、ソースを最後のリリースの時点までロールバックしてから、再現を試みる必要があります。正常に再現できた場合は、テストを作成して、後のコミットで修正されることを確認できます。