原因が分からない不具合の修正手順です。
基本的な事しか書いてません。
僕は基本的なことだと思っていたのですが、意外と手順が守られていない場合があるので記しておこうと思います。
（CI環境があるとか、テストコード資産があってデグレ確認が簡単に出来る場合は少し違うかもしれません）
1.不具合を再現させる
まず、不具合を再現させることが出来る環境を構築するのが最優先です。
インシデントレポートや伝聞はあまり信じないで、不具合が再現出来る環境を構築して、自分の目で不具合を確認しましょう。
最初に、不具合の場所の特定や検討をすることは検討違いなことをしていて時間を無駄にすることが多いと思います。
そもそも不具合が再現しないということもありますし、不具合の再現環境を構築しないで不具合の修正内容を検討しても、修正内容が正しいのかの検討が出来ないです。
2.不具合の再現性の向上施策を検討する
次にやることは不具合の再現性を高めることです。
１００％不具合が発生出来るようになっていることがベストですが、１００％とは行かなくてもどうしたら発生確率を高く出来るかを考えます。
また、再現させるまでの手順を短くして簡単に不具合が出せるようにするとか、影響してる要因を一つずつ取り除いていくなどの作業もあります。
不具合を発生させることが出来る最低限のソースコードや、環境を見つけられればベストです。
3.不具合の対策の検討
ここで初めて対策方法の検討に入ります。
2を終えている段階で大体の修正方針は見えているかもしれません。
何処を修正すれば不具合が修正出来るのかを検討するのはもちろんですが、その修正の影響範囲を調査して、不具合修正時に何をテストする必要があるのかを検討することも含まれます。
また、不具合の情報を出力する機能を実装することも有効です。これで不具合が出ている間は不具合であるという状態が明確になり、不具合を修正した後では不具合が修正されたことが明確になります。こうすることで、不具合が再度発生した場合は、そのルートで不具合になっていることを明確にすることが出来ます。（7of9さん指摘）
4.不具合対策の確認
3で作り込んだプログラムの動作を確認して修正されていることを確認します。
確認作業は、単体テスト、結合テスト、システムテスト等のテストレベル別に確認作業が行えるとベストです。
(5.リファクタリング)
不具合の対策後は、ツギハギのようなプログラムになっていることがあります。
そのため、不具合の対策後にリファクタリングを行い、ソースコードをクリーンな状態に保つことは大切です。
なお、リファクタリングを行った後は、デグレードが発生していないことの確認テストは再度行う必要があります。
不具合が発生したソースコードの元の状態がひどすぎる場合は、3の前にソースコード理解も含めてリファクタリングを行うのも良いかもしれません。ただ、その時はリファクタリングを行い、デグレードが発生していないことを確認してから3の不具合対策の検討に入ります。
確認作業を2回することになりますが、リファクタリングと、不具合対策の修正は分けて作業を行う必要があります。一度にテストすると、テストがNGだった場合に、何が原因でテストがNGになったのかが分かりにくくなる場合があります。
最後に
ただ、1の不具合を再現させることが最優先だよってことが言いたかっただけです。
ただ殴り書きしただけなので、意見、反論あったらコメントください。