テスト漏れを防ごうとすれば,おのずからテスト範囲は広がり,それに引きずられてテスト時間も長くなる。例えばミサワホームの受発注システムでは,改造時に約1日をかけてテストすることもある。網戸やドアノブなどを単品で扱う「個別注文」は,全部で7パターン程度の発注方式がある。「以前は,改造によって影響がありそうなパターンのみ選んでテストしていたが,パターン漏れによるトラブルを経験した」(松尾氏)。そこで,「受注」「納品」といった機能単位で,改造を加えた機能に対して,すべての発注パターンをテストするように変えた。

 テストを効率化する方法の一つに,自動機能テスト・ツールの利用が挙げられる(表1)。マウスやキーボードの操作をテスト・シナリオとして記録しておき,その実行結果をレポートすることが基本機能である。

表1●自動機能テスト・ツールの例
[画像のクリックで拡大表示]
表1●自動機能テスト・ツールの例

 INAXの松中氏は,自動機能テスト・ツール「WinRunner」をこの春に導入した。「プログラム開発に時間はかからないが,(影響が無いことを確かめる)検証パターンが膨大。ツールを使ってなんとか簡単にテスト品質を上げられないか試している」。

 住友電気工業では,商用フレームワークの改造作業において自動機能テスト・ツールを利用している。ツールによるテストに先立ち,単体テストを二重に行う。その上で,「e-Tester」を使ったシナリオを使った自動テストを実施。「案件をこなすたびに,シナリオを継ぎ足し,今では500~600までになった。これを半日かけて実行している」(中村氏)。

“きれいな”環境でテストする

 改造時のテストでは,サーバーやテスト・データといった「環境」がきちんと整備されているかも,テストの品質や効率を左右するポイントだ。開発のための「開発環境」に加えて,「検証環境」が用意できれば,本番さながらのテストを実行しやすい。大成建設やヤナセがそのような環境を持っている

 検証環境を用意する目的は二つ。一つは,プログラムを本番環境にリリースする前に,利用者にそこでテストしてもらうこと。テスト環境を使うことも考えられるが,「テスト環境は(中途半端なデータやプログラムがあるなど)汚れているので,別途,検証環境を設けて利用者に確認してもらっている」(ヤナセの柴田氏)。

 ヤナセでは,本番環境のバックアップ・データを定期的にコピーして,検証環境を維持している(図1)。「検証環境はテストだけでなく,利用者の操作教育やトラブルの再現調査などにも使い,できるだけ遊ばせないようにしている」(柴田氏)。

図1●検証環境を有効活用するヤナセ
図1●検証環境を有効活用するヤナセ
開発環境と本番環境の間に「検証環境」を設け,本番さながらのテストを行う。本番からコピーしたテスト・データに対して,更新処理も可能だ。本番システムを止めずにトラブルの再現調査ができるなど,検証環境を持つメリットは大きい
[画像のクリックで拡大表示]

 検証環境を抱えるもう一つの目的は,そこで負荷テストを充実させることにある。「DBMSがらみの変更は,本番並みのデータ量で負荷テストを行わないと性能面で不安が残る」(NTTデータ セキスイシステムズの上野氏)。その点,ヤナセのように,本番と同等のデータが使えることはテスト品質の向上につながる。もちろん,DBMSのオプティマイザの挙動による影響もあり,本番でも寸分たがわぬ性能を見込めるわけではないが,本番リリースに向けた心強さは格段に違うだろう。