システム・テストの構造

52週アグリMD生産工程管理システム
この記事は約3分で読めます。

上で述べたテスト基準日をもっと具体的に見てみましょう。

例題にした52週農業生産工程管理システムのテスト基準日を示します。

「売上登録、請求、回収」の列には、カットオーバー日の7月1日をテスト基準日の初日として、平常日、月末、月初、締め日が続いています。

これらの項目に、「売上代金支払」と「在庫管理」のテスト基準日を付け加えて、全体のテスト基準日が設定されています。

テスト基準日は、業務機能のすべてを確認できることが必須であります。

一方で、テスト基準日の日数は少ないほど良いのです。

少なければシステム・テストの期間が短くなり、工数も小さくなります。

こうした理由があるので、このテスト基準日の設定には、業務の専門家を投入するのが通常です。

表に記載したテスト基準日は合計20日で、サイクル・テストはこれらすべての日付に対して行われます。

表の右に「○」が付いているのは、運用テスト「OT」を実施するテスト基準日を示します。

運用テストのテスト基準日はサイクル・テストのそれに比べ、少なくなるようです。

設定したテスト基準日を適用するために、システム・テストは図に示すような構造をなしている必要があります。

この例では、サイクル・テストが2回で、運用テストも2回です。

点線で示すように運用テストはサイクル・テストの後続で行われ、運用テストの2回目が無事に終了すれば、本番のカットオーバーを迎えます。

それぞれのテストに向けて、既存システムからのデータ移行が行われるが、サイクル・テストでは、移行データからサイクル・テストの取引条件を満たす最小のデータを抜き出して、テスト用のデータベースとします。

運用テストでは、移行データの全量を使用します。

サイクル・テストと運用テストを2回に分けたのは、予定したテスト基準日を2回、回すことを意味しています。

サイクル・テストに例えると、1回目のサイクル・テストで特定の取引に障害が発生した場合、普通はそこで修正を行って再テストします。

障害の修復に時間がかかって再テストに間に合わない場合には、その障害に関係する後続のテストはできなくなります。

しかし、生涯に関係しないテストは前に進めることができるので、できるテストを行ってテスト項目を消化することが原則です。

障害が発生した取引とその後続の取引は、2回目のサイクル・テストの該当のテスト基準日までに、修正をして迎える計画を組むことができます。

サイクル・テストが1回だけでは、このようなことはできません。

障害が解決されるまで、テストは停止してしまいます。

サイクル・テストと運用テストは、このように複数回行うことが多く、特に企業の基幹システムのような大きなプロジェクトでは4回が多いようです。

このサイクル・テストと運用テストの実施のために、テスト計画書を作成します。

計画書に従って、テスト内容を示すテスト・シナリオを作成します。

テスト・シナリオは、一連の機能を確認するテストの集合体です。

続いて、テスト・データの準備を行います。

テスト用のデータベースは、データ移行システムを使って作成します。

手作業で作成することもあるが、データ移行システムの検証も兼ねて、移行システムで生成した移行データを使う場合が多いのです。

以上のような構造を持つシステム・テストを組み上げるには、かなりの経験が必要となります。

初めてシステム・テストを担当した人は、きちんとした計画を立てることは無理でしょう。