バグの修正がバグを生む
ちょっと今ヤバイことになっています。
かつて出したバグがあります。
修正パッチを当てて「解決済み」という風に顧客に説明したのですが、
なんと今になって解決したどころかそのパッチを当てたせいで
更に別のバグが発生していたことが判明しました。
しかも。。。それ、自分がコーディングした部分です。。。
かなりヤバイです。
コーディングした後にテスターに引き継いで、
そのテスターも見逃してしまったのですが、元は自分が書いた部分です。
それ相応の責任をとることになるでしょうね。汗
バグの修正後確認を行うと、「バグが治っているかどうか」ということだけに
心が奪われがちですが、バグを修正することによって生じうる
二次的問題にも同程度に目を向けなければダメですね。
既存部分の調査と調査結果のレビュー、そして確認テストは徹底的に行うこと。
バグが発生した関数、それに関連ある関数のルートは全て通すくらいの
再テストは絶対にやるべき。
今回は時間がとれずレビューがまともにできなかったことと、
調査範囲が狭すぎたことが原因で、二次的なバグを呼んでしまいました。
バグ修正の二次的影響というはバグ発生個所の前後だけでなく、
意外なところで出たりします。
身をもってバグの恐ろしさというものを体験してる23歳でした。
しばらく休みがなさそうです。。。
かつて出したバグがあります。
修正パッチを当てて「解決済み」という風に顧客に説明したのですが、
なんと今になって解決したどころかそのパッチを当てたせいで
更に別のバグが発生していたことが判明しました。
しかも。。。それ、自分がコーディングした部分です。。。
かなりヤバイです。
コーディングした後にテスターに引き継いで、
そのテスターも見逃してしまったのですが、元は自分が書いた部分です。
それ相応の責任をとることになるでしょうね。汗
バグの修正後確認を行うと、「バグが治っているかどうか」ということだけに
心が奪われがちですが、バグを修正することによって生じうる
二次的問題にも同程度に目を向けなければダメですね。
既存部分の調査と調査結果のレビュー、そして確認テストは徹底的に行うこと。
バグが発生した関数、それに関連ある関数のルートは全て通すくらいの
再テストは絶対にやるべき。
今回は時間がとれずレビューがまともにできなかったことと、
調査範囲が狭すぎたことが原因で、二次的なバグを呼んでしまいました。
バグ修正の二次的影響というはバグ発生個所の前後だけでなく、
意外なところで出たりします。
身をもってバグの恐ろしさというものを体験してる23歳でした。
しばらく休みがなさそうです。。。