バグ改修RTA

4ステップに分けてみました

1.再現
2.原因解明
3.類似箇所の検索
4.動作確認

1.再現

ひとえにバグといっても

商用環境で起きたのか検証環境で起きたのか
レコード起因のものなのか
ハードコーディングの改修によって生まれたのか
ログから調査可能なものか

など様々ですので
とりあえず調べてざっくりわかったら、まずはローカル環境で再現してみるのが一番でしょう
わかりきっているバグならこの工程を飛ばしても構わないかと

2.原因解明

再現することでわかることもあれば、それでもなお原因不明なこともあります
コードを追ってすぐにわかれば良いですが、時間がかかりそうだと思ったら迷わずデバッグモードで起動しましょう
怪しい箇所がわかっている場合はそこにブレークポイント
わからない場合はすべてのメソッドにブレークポイントをうって、一つ一つ値が正常か確かめます

この工程で改修方法が分からない場合はほぼ詰みです
詰みかけている場合は以下を意識しましょう

a) レコード不良ではないか
b) 要件として考慮されている動きか(考慮漏れによるバグ)
c) 一見正しくみえるが実は欠陥のあるロジックではないか

a) そもそも起こりえない不正レコードならば、改修の必要がなくなる可能性もあります
b) 考慮漏れバグの場合は、分岐の全体像を再確認する必要があります
　多くの場合が大規模改修や要件の再調整に繋がるので、いったん頭を冷やしましょう
c) switch文の中でbreakを書き忘れたりなど、気づきにくいロジックミスも起こりえますが
　これはデバッグで挙動を追うことで検知できます

3.類似箇所の検索

原因を解明することができたら、さくっと直しましょう
重要なのは、他に類似バグが存在しないことの保証です
無論デグレがないことも確認してください

Enum定義値のバグや共通メソッド内部でバグがあった場合などは呼び出し元検索
類似ではあるが違う処理を行っている箇所を正規表現テキスト検索などで強引にでも洗い出し
同バグが他にないことを徹底してください

4.動作確認

バグ改修、ないし付随するすべてのバグ改修が終わったら、動作確認を行います
起こりうるケース、起こりえないが入力可能なケースなど、考慮漏れがないように確認ケースを列挙しましょう
大きな改修の場合はテスト仕様書を作成することも視野に入れてください