開発した本人にテストを任せると,「動くはず」という過信から,どうしてもチェックが甘くなる。このため,テストは決して開発者任せにしてはいけない。特にオフショア開発の場合には,「正常系はテストしても,異常系は全くテストしていないなど,とんでもないプログラムが納品されることがある」(SIベンダーのレッドフォックス プロジェクト統括マネージャ 末岡孝章氏)。できれば,設計,開発,テストを,それぞれ別の人が担当できれば理想だろう。だが,そこまでの人繰りは難しいことは多い。その場合,「せめてプロジェクト全体で統一したテスト方針を作り,各プログラムのテスト・ケースは開発者とは別の担当者にレビューしてもらう」(末岡氏)といった体制を作るべきである。

 テスト方針では,テストの進め方も忘れず規定したい。最近の開発ソフトは単体テスト・ツールを呼び出せるため,単体テストとコーディングを一体化するスタイルが定着しつつある。だが,こうしたテストの仕方では,特定のパターンのバグが紛れ込みやすいと,日立システムアンドサービスの上野政彦氏(産業システムサービス事業部 UL技師)は指摘する。

 典型的なのは,プログラムAで禁則処理のライブラリを作り,その後別のプログラムBでそのライブラリを改修して使う,といったケースである。プログラムAの開発時にライブラリを含めてテストを実施し,正常動作を確認。次にプログラムBを開発するときに改修したライブラリを含めてテストを実施し,正常動作を確認する。実はこのとき,ライブラリの改修でプログラムAの動作は仕様と合致しなくなっているのだが,開発者は「プログラムAはテスト済み」と思い込み再テストを実施しない――。単体テストとコーディングの一体化には,回帰テストを漏らしやすい一面もあるので気をつけたい。