こんにちは！
フリーランスプログラマーの阿部拓哉です！
とあるパッケージ製品の開発、保守、運用に携わって約6年が経ちます。
慣れるにつれて、システム利用現場で発生した障害や不具合（バグ）の原因を、早く突き止めることができるようになります。
仕様通りに動作するはずなんだけどなぁ、と思っていても、
デバッグしてみると思いもよらない原因が潜んでいてびっくり！
なんてことは、開発経験者なら誰しも一度は経験したことがあるのではないでしょうか。
僕の場合、バグの原因はだいたい次のようなことが多いと感じています。
（１）新しい機能の追加に対して、既存機能に対する影響を考慮していなかった
新機能が増えたことで、既存機能に対するインプットが知らない間に変わっていたり、今まで考慮していなかったパターンに対する養生が必要になったり。
追加機能のテストは綿密にやるけど、既存部分のきわどいテストケースってなかなか思いつかないんですよね。
（２）異常発生時の動作や、想定外の操作に対して不備があった
システムエラーが起きたときはどうするか、どうエラーハンドリングするのが適切か、異常時の動作をイメージするにはシステムを熟知している必要があります。
また、「ユーザがそんな操作をするとは想定していなかった」と、ときには言い訳をしたくなることも正直あります（笑）。
異常系のテストこそ、開発段階でしっかりやっておくべきだと痛感しています。
開発におけるテストの目的は、リリース前に不具合（バグ）を摘出することなので、バグが出たらよかったと思うべきなのかもしれません。
コードを書いたのが自分である場合は、なかなかそう思えないかもしれませんが…
綿密なテストをするというミクロな視点を養うには、システム全体のことを考慮するマクロな視点も同時に必要なんだな、と日々感じています。
最後までお読みいただきありがとうございました！
入会申込
ログイン
