上で述べたテスト基準日をもっと具体的に見てみましょう。
例題にした５２週農業生産工程管理システムのテスト基準日を示します。
「売上登録、請求、回収」の列には、カットオーバー日の７月１日をテスト基準日の初日として、平常日、月末、月初、締め日が続いています。
これらの項目に、「売上代金支払」と「在庫管理」のテスト基準日を付け加えて、全体のテスト基準日が設定されています。
テスト基準日は、業務機能のすべてを確認できることが必須であります。
一方で、テスト基準日の日数は少ないほど良いのです。
少なければシステム・テストの期間が短くなり、工数も小さくなります。
こうした理由があるので、このテスト基準日の設定には、業務の専門家を投入するのが通常です。
表に記載したテスト基準日は合計２０日で、サイクル・テストはこれらすべての日付に対して行われます。
表の右に「○」が付いているのは、運用テスト「ＯＴ」を実施するテスト基準日を示します。
運用テストのテスト基準日はサイクル・テストのそれに比べ、少なくなるようです。
設定したテスト基準日を適用するために、システム・テストは図に示すような構造をなしている必要があります。
この例では、サイクル・テストが２回で、運用テストも２回です。
点線で示すように運用テストはサイクル・テストの後続で行われ、運用テストの２回目が無事に終了すれば、本番のカットオーバーを迎えます。
それぞれのテストに向けて、既存システムからのデータ移行が行われるが、サイクル・テストでは、移行データからサイクル・テストの取引条件を満たす最小のデータを抜き出して、テスト用のデータベースとします。
運用テストでは、移行データの全量を使用します。
サイクル・テストと運用テストを２回に分けたのは、予定したテスト基準日を２回、回すことを意味しています。
サイクル・テストに例えると、１回目のサイクル・テストで特定の取引に障害が発生した場合、普通はそこで修正を行って再テストします。
障害の修復に時間がかかって再テストに間に合わない場合には、その障害に関係する後続のテストはできなくなります。
しかし、生涯に関係しないテストは前に進めることができるので、できるテストを行ってテスト項目を消化することが原則です。
障害が発生した取引とその後続の取引は、２回目のサイクル・テストの該当のテスト基準日までに、修正をして迎える計画を組むことができます。
サイクル・テストが１回だけでは、このようなことはできません。
障害が解決されるまで、テストは停止してしまいます。
サイクル・テストと運用テストは、このように複数回行うことが多く、特に企業の基幹システムのような大きなプロジェクトでは４回が多いようです。
このサイクル・テストと運用テストの実施のために、テスト計画書を作成します。
計画書に従って、テスト内容を示すテスト・シナリオを作成します。
テスト・シナリオは、一連の機能を確認するテストの集合体です。
続いて、テスト・データの準備を行います。
テスト用のデータベースは、データ移行システムを使って作成します。
手作業で作成することもあるが、データ移行システムの検証も兼ねて、移行システムで生成した移行データを使う場合が多いのです。
以上のような構造を持つシステム・テストを組み上げるには、かなりの経験が必要となります。
初めてシステム・テストを担当した人は、きちんとした計画を立てることは無理でしょう。
