プログラムの変更が終わったら,いよいよテストだ。大成建設の八木義之氏(情報企画部 運用担当グループ 次長)は,「直したところ以外は,本当に触っていないことを確認する必要がある」と,ソフトウエアを改造したときのテストの特徴を語る。

 難しいのは,改造の影響をどこまで見越してテスト範囲に織り込むかだ。その範囲が狭すぎればバグを取り逃がしてしまう。反対に広すぎると,手間がかさんでしまう。電通国際情報サービスの田邊氏は,「普通のアプリケーションであれば,影響範囲を絞り込んでテストする。ただし,共通モジュールやフレームワークなど影響が大きいものに手を入れた場合は,リグレッション・テストを行うこともある」と,変更対象によってテスト範囲にメリハリを付けている。

 またテストは,範囲を適正化することに合わせて,作業の効率化も図りたい。たびたび改造を行うような環境では,ツールを使った自動テストの仕組みは必須といえるだろう。以下では,(1)適切なテスト範囲を押さえる,(2)テストを効率化する,(3)安全に本番リリース(移行)する――の三つの作業を通じてテストから本番リリースまでのポイントを解説する。

テスト・ボリュームの基準を持つ

 テスト範囲を決めるに当たり,まず,テストのボリュームについて基準を持ちたい。なんの基準もなく,いたずらにデグレードの不安に怯えていては,テスト範囲は果てしなく広がる。

 中堅インテグレータのクオリカでは,「ソースコードを何ライン変えたら,どれだけテストを行うか基準として決めてある」(システム本部 第一事業部 システム第三部 部長 栗田敏明氏)。その「基準値範囲」を見ると,改造型開発における値は,新規開発の4割~5割増しになっている(図1)。各プロジェクトでは,基準値範囲を参考にして,テストのボリュームを決める。この基準値範囲の値は現在,厳しくする方向で見直しを進めているという。

図1●改造のミスはトラブルに直結する
図1●改造に伴うテスト量を見積もるクオリカの基準
クオリカでは,開発規模に対するテスト量を,全社的な品質基準として決めている。改造型開発の基準値は,新規開発に若干ボリュームを上乗せしてある。この基準値を参考に,プロジェクト案件ごとに,単体テスト/結合テスト/システム・テストのテスト量を決めている
[画像のクリックで拡大表示]

 ジャステックは,過去の開発実績から,テスト項目数の見積もりモデルを作った。これは第5回で紹介した改造工数の見積もりモデルに考え方は近い。「巻き込み範囲」と「巻き込み率」という二つのパラメータを使い,ベースラインからの,テスト項目数の増加率が見積もれるようになっている。「テストすべき範囲」に加えて,「その範囲内に追加したプログラムの密度」をテスト項目数の変動要因として考慮しているのである。

この先は会員の登録が必要です。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら