トレンドマイクロ、テスト工程の不備が命取りに。

パッケージ製品ともなると、記事にあるように対応しているOSや環境毎に一連のテストを繰り返さなければいけないでしょうし、パターンファイルともなるとタイトな時間で行わなければならないでしょうから、俺の知っている工程よりも数倍大変だとは思いますが。

しかし一番の問題は、テスト工程に不備があったことだ。通常、パターンファイルを公開する前には製品とOSの組み合わせを確認するため複数のOS上で動作確認を行う。しかし今回はWindows XP Service Pack 2環境におけるテストが人為的ミスにより行われなかった。

開発していると、テストの甘さで結構大変な目に遭ったりします。テストでは問題が無かったのに何で本番環境で…なんて事も起きたりしますが、テスト方法に問題があったという事も意外と多かったりする訳です。Microsoft等それなりの規模の企業だとテスト専任スタッフがいるそうですが、ウチの会社みたいな所だとPGが行います。
時間や人員に余裕がある場合は例えば、AさんがcodingしたモノA'をBさんがテストして、Bさんの書いたB'はCさんがチェックする…という様に開発した人とは別の人がテストするという流れにするのです。しかし、これが時間が無かったり人が少なかったりすると…AさんはB'を、BさんがA'をテストするという形であったり、Aさんが自分の書いたA'をテストするという事になったりします。無論この中では最後のケースが一番危険で、トラブルの元であったり、bug発見が遅れたりする大きな要因です。これに加えて、テスト仕様書までもAさんが書いたりするとほぼ間違いなくbugが発見されないままリリースされたりします。
Aさんは設計書通りにcodingしたと思い込んだまま、自分の解釈のままテスト仕様書を書いてしまうので、この段階で本来はチェックされるべきある条件が取り込まれないという事が起きかねません。更にその仕様書を元にテストを行うので、結果的に一定条件で致命的なエラーが起きてしまうbugを含んだままという事も無い話しではありません。無論、テストを行う人が与えるテスト条件が杜撰な事で同様にスルーされてしまう事もあります。これは仕様書に予め細かく条件を決めておけば避けられる事でもありますが、流れ作業的に開発からテストまで1人でやらせたりすると発生し得るので、上がちゃんとチェックする必要はありますね。
面倒臭くてつい手を抜こうかと思いたくなるテストですが、手を抜いたらそれだけ痛い目を見るという…。