プログラムの変更が終わったら，いよいよテストだ。大成建設の八木義之氏（情報企画部 運用担当グループ 次長）は，「直したところ以外は，本当に触っていないことを確認する必要がある」と，ソフトウエアを改造したときのテストの特徴を語る。 難しいのは，改造の影響をどこまで見越してテスト範囲に織り込むかだ。その範囲が狭すぎればバグを取り逃がしてしまう。反対に広すぎると，手間がかさんでしまう。電通国際情報サービスの田邊氏は，「普通のアプリケーションであれば，影響範囲を絞り込んでテストする。ただし，共通モジュールやフレームワークなど影響が大きいものに手を入れた場合は，リグレッション・テストを行うこともある」と，変更対象によってテスト範囲にメリハリを付けている。 またテストは，範囲を適正化することに合わせて，作業の効率化も図りたい。たびたび改造を行うような環境では，ツールを使った自動テストの仕組みは必須といえるだろう。以下では，（1）適切なテスト範囲を押さえる，（2）テストを効率化する，（3）安全に本番リリース（移行）する――の三つの作業を通じてテストから本番リリースまでのポイントを解説する。 テスト・ボリュームの基準を持つテスト範囲を決めるに当たり，まず，テストのボリュームについて基準を持ちたい。なんの基準もなく，いたずらにデグレードの不安に怯えていては，テスト範囲は果てしなく広がる。 中堅インテグレータのクオリカでは，「ソースコードを何ライン変えたら，どれだけテストを行うか基準として決めてある」（システム本部 第一事業部 システム第三部 部長 栗田敏明氏）。その「基準値範囲」を見ると，改造型開発における値は，新規開発の4割～5割増しになっている（図1）。各プロジェクトでは，基準値範囲を参考にして，テストのボリュームを決める。この基準値範囲の値は現在，厳しくする方向で見直しを進めているという。
ジャステックは，過去の開発実績から，テスト項目数の見積もりモデルを作った。これは第5回で紹介した改造工数の見積もりモデルに考え方は近い。「巻き込み範囲」と「巻き込み率」という二つのパラメータを使い，ベースラインからの，テスト項目数の増加率が見積もれるようになっている。「テストすべき範囲」に加えて，「その範囲内に追加したプログラムの密度」をテスト項目数の変動要因として考慮しているのである。 テスト項目を継続して集めるテストすべきボリュームが見えたら，テスト項目を洗い出す。改造ならではのポイントは，「変更したことで余計な影響を与えていないことを証明するためのテスト項目」をうまく集めることだ。 こうしたテスト項目の元になるのは，新規開発の際に行ったテストである。「アプリケーションの基盤となる機能に手を加えたときは，開発時に行ったテスト・シナリオを実行して，データベースの処理結果に誤りが無いことを確認している。こうしたテストを手早く行うためには，新規開発の設計時にテスト・パターンを盛り込んでおくことが望ましい」（NTTデータ セキスイシステムズの上野氏）。 テスト項目は，改造を繰り返す中で継続して集めて，漏れを減らしていく。その際に心掛けたいのが，（1）テストのノウハウをプロジェクト間で共有すること，（2）フィードバックによりテスト項目を充実させることである。 富士通のチェックシートから，どんなテスト項目やチェックが必要か見ていこう（図2）。これは，金融APMセンターと呼ぶプロジェクトで，改造型開発のテストを行うときに利用する資料である。チェックシートは，（1）基本テスト項目，（2）横展開チェックシート，（3）品質チェックシート，の三つがある。
見直すルールも決めておく（1）の基本テスト項目は，プログラムを改造した際に，変更個所にかかわるテストのほかに，必ず実施すべきテスト項目をまとめたもの。「領収書が発行できるか」というように，アプリケーションの固有機能を対象としたテスト項目が並んでいる。 （2）の横展開チェックシートは，「日付」や「権限」など，アプリケーションに共通的な処理をまとめたチェックシート。「マイナス表示の属性は適正か」「英数字・数字の属性は適正か」といった，データ属性関連の項目もある。「APM（Application Portfolio Management）は，顧客システムの保守コストを圧縮して，新規投資にシフトしてもらうことを目的としたサービス。APMサービスと呼ぶ土台の上に，業種ごとにAPMセンターと呼ぶ個別プロジェクトがある」（サービスビジネス本部 APMサービス推進担当 専任部長 橋本俊明氏）。プロジェクトごとのノウハウを，横展開チェックシートによって共有しているのである。 （3）の品質チェックシートは，デグレードや他のサブシステムへの影響調査，および本番リリースに伴う作業漏れをチェックするためのもの。「オンライン・レスポンスが著しく低下していないか」など，性能確認を促す項目も用意されている。 これらのチェックシートは，内容を見直すタイミングが二つ決まっている。一つは，顧客による本番リリース検証がNGになったタイミング（図2の（3））。テスト項目の漏れが原因だった場合は，その項目を基本テスト項目に加える。もう一つは，本番環境でなんらかの障害が発生したタイミング。再発防止策を作成すると同時に，基本テスト項目と横展開チェックシートの内容を見直している。 |
ソフトウエア改造力 >
