プログラムの変更が終わったら，いよいよテストだ。大成建設の八木義之氏（情報企画部 運用担当グループ 次長）は，「直したところ以外は，本当に触っていないことを確認する必要がある」と，ソフトウエアを改造したときのテストの特徴を語る。
難しいのは，改造の影響をどこまで見越してテスト範囲に織り込むかだ。その範囲が狭すぎればバグを取り逃がしてしまう。反対に広すぎると，手間がかさんでしまう。電通国際情報サービスの田邊氏は，「普通のアプリケーションであれば，影響範囲を絞り込んでテストする。ただし，共通モジュールやフレームワークなど影響が大きいものに手を入れた場合は，リグレッション・テストを行うこともある」と，変更対象によってテスト範囲にメリハリを付けている。
またテストは，範囲を適正化することに合わせて，作業の効率化も図りたい。たびたび改造を行うような環境では，ツールを使った自動テストの仕組みは必須といえるだろう。以下では，（1）適切なテスト範囲を押さえる，（2）テストを効率化する，（3）安全に本番リリース（移行）する――の三つの作業を通じてテストから本番リリースまでのポイントを解説する。
テスト・ボリュームの基準を持つ
テスト範囲を決めるに当たり，まず，テストのボリュームについて基準を持ちたい。なんの基準もなく，いたずらにデグレードの不安に怯えていては，テスト範囲は果てしなく広がる。
中堅インテグレータのクオリカでは，「ソースコードを何ライン変えたら，どれだけテストを行うか基準として決めてある」（システム本部 第一事業部 システム第三部 部長 栗田敏明氏）。その「基準値範囲」を見ると，改造型開発における値は，新規開発の4割～5割増しになっている（図1）。各プロジェクトでは，基準値範囲を参考にして，テストのボリュームを決める。この基準値範囲の値は現在，厳しくする方向で見直しを進めているという。
 |
| 図1●改造に伴うテスト量を見積もるクオリカの基準 クオリカでは，開発規模に対するテスト量を，全社的な品質基準として決めている。改造型開発の基準値は，新規開発に若干ボリュームを上乗せしてある。この基準値を参考に，プロジェクト案件ごとに，単体テスト/結合テスト/システム・テストのテスト量を決めている [画像のクリックで拡大表示] |
ジャステックは，過去の開発実績から，テスト項目数の見積もりモデルを作った。これは第5回で紹介した改造工数の見積もりモデルに考え方は近い。「巻き込み範囲」と「巻き込み率」という二つのパラメータを使い，ベースラインからの，テスト項目数の増加率が見積もれるようになっている。「テストすべき範囲」に加えて，「その範囲内に追加したプログラムの密度」をテスト項目数の変動要因として考慮しているのである。
