COBOLコンソーシアム利用技術分科会
清水 真 (東京システムハウス株式会社 ビジネスイノベーション事業部)
単純移行のプログラム修正は“項目名を一律に置換していく”といった機械的な修正が多く、また開発期間も短いことからテストが短縮されがちです。
しかし、機械的な修正であっても移行後のシステム資源に手が加えられていることに変わりはありません。新規開発と同様に不具合が隠れていると考えるべきでしょう。ここでは照合テストの説明をします。
照合テストの手法は、システム移行前後のアウトプットを付け合わせるという極めてわかり易い方法です。
ここで問題になるのは、誰がテスト・データを作成すべきか、ということです。ユーザー主導でテスト・データを準備することがもっとも効率が良く、テスト・データの漏れも少ないといえます。
仮に、日常業務の多忙を理由に、ユーザーが開発側にテスト・データの作成を依頼した場合、開発側には次のような作業が必要になります。
各ジョブの内容を理解する→漏れのないテスト・データ（更新前データ）を作成する→JCLに的確な実行パラメータを設定する→更新前データを採取する→的確な順序でジョブを実行する→更新後データを採取する──これらの作業を、すべてのジョブに対して実行する必要があるため、当然、作業時間とコストはどうしても膨らんでしまいます。さらに開発側にとっては不慣れな環境だけに、操作ミスによる時間のロスも相当量を覚悟しておかなければならなりません。
一方ユーザーは、開発側が習得できない「知識と運用実績」を既に持ち合せています。単位時間当たりの作業効率の観点では、どちらが担当すべきは比べるまでもないでしょう。ユーザーにとってテスト・データ作成に必要なものは、パワー（作業人員と時間）のみです。ユーザーがテスト・データの準備をすべてこなすパワーがどうしてもない場合でも、例えば開発側の人間を作業者として利用するなど、ユーザー主導で進めることは可能です。
なお、テスト・データは本番データを基に作成することが効率的でしょう。