- ベストアンサー!Mizuテスター
今までの開発経験からすると、単体テストケース、結合テストケースを正しい視点で、量産することだと思います。
単体テストケースの場合ですと
実装をした時点(いや、実装する前の場合もありますが)、例えば、関数(C++ではメソッド)単位で、複数の単体テストケースを作成する。
1関数の中には、正常系、異常系のパス(実装コード)があり、この単体テストケースを実行することで、正しい正常系の動作、異常系の動作をするか
どうかを確かめるイメージです。一度作成してしまうと、回帰テストする場合は、自動で実行できるので、人手もかからないメリットがありますが
コード修正した場合、期待値を修正する必要があったりなどテストケース自体を修正する必要もあります。
しかし、このテストケースのおかげで、回帰テストの手間が、激減するのは、間違いなく(人間が回帰テストは、やればやるほど、モチベーションが下がり、見逃しなど、テストミスなども発生しやすい)環境が変わった場合に、発生するバグにおいても、先に述べたテストケースを実行すれば、バグの原因となる関数が明確になるため、原因特定にも時間がかからないと思います。対策案を検討する時間は、それなりに調査時間がかかるかもしれませんが、障害となる関数が明確になるメリットは、大きいと感じます。
- サカナクンプログラマー
現代のソフトウェア開発は既存のライブラリを組み合わせて
短いスパンで更新を繰り返すため100%バグのないプログラムは難しいですよね。重要なバグや発生確率が高いバグはMizuさんの仰るとおりで
テストコードを書くことでバグが発見しやすくなります。環境が変わったとしても、UIテストツールなどでテストを自動化しておけば
短時間で繰り返しテストできますのでおすすめです。>原因は解らないが環境が変わった場合にごくまれに発生するバグ
私は再現性のないバグ対応に1週間対応して、その時は解決できませんでした。
それからは開き直って対応してません。いろんなライブラリを組み合わせてますので
仕方がないことだと思います。ライブラリやOSが更新されることでバグが直ることがよくありますので
100%バグを潰すような考え方は今の時代は間違っているような気がします。※ 医療現場など人の命にかかわるような現場だったり金融系のプロジェクトは対応しないといけません。