栽培プロジェクトの要件定義フェーズから開発実施フェーズまでは、その開発フェーズで定義された栽培プロジェクト農産物を作成する物作りが、作業の本体です。
統合テストとシステム・テストの両フェーズでは、この物作りの作業は少なく、新システムの品質を確保するテストが大半を占めます。
統合テストとシステム・テストでは、概念とテストのやり方が全く異なります。
システム・テストの概念をより明確にするため、両者を比較してみます。
まず統合テストでは、サブシステム内部の機能と、サブシステム間のインターフェーズのテストを行います。
サブシステム内部では、そこにある複数の取引を集めた機能の品質確認と、その機能間の整合性の確認が行われます。
テストの実施単位はサブシステムで、サブシステムごとにテスト環境を持ち、それぞれ独自のテスト・スケジュールに従って、テストは推進されます。
サブシステム間インターフェース・テストは、複数のサブシステムをまたぐ共通テストとして、連携して行われます。
大きなインターフェースがある場合には、専用のテスト環境を設けて行う場合もあります。
これはインターフェース・テストの影響で、サブシステム内部のテスト・スケジュールに変更が発生することを防ぎたいためです。
一方、システム・テストにはこのサブシステムの概念がありません。
新システム全体の機能を確認するためにテストを行います。
それと同時に、そのシステムのコンピュータの運用が可能かも確認します。
これらのテストを行うため、テスト基準備を設定し、その基準日に発生するすべての取引を入力します。
このテスト基準日とは業務の日付を表し、売上の取引が発生した都度に売上伝票に記載される日付です。
テスト基準日を前に進めていくことで、すべての商品・サービスの機能を確認します。
システム・テストは、サイクル・テストと運用テストという２つのテストから構成されます。
サイクル・テスト（ＣＴ）では、テスト基準日単位に、商品・サービスの機能を確認します。
商品・サービスの発生から消滅までを意味する「ライフ・サイクル」が、このサイクル・テストの名前の由来です。
このテストでは、できるだけ少ない量のデータベースを使い、すべての取引を打鍵して結果の検証を行います。
「少ない量のデータベース」を使うのは、格納されたデータ件数が少ないほど、検証時間が短くなるためです。
特に残高確認ではその効果が大きいでしょう。
例えば１００件のデータを持つデータベースの残高検証は、１０．０００件の場合と比べ工数が圧倒的に少ないのです。
そして、少ないほど検証品質が高くなります。
検証に適した「少ない量のデータベース」を実現するためには、取引・サービスの条件を分析して、条件のすべてを表現する最小のデータの組み合わせを作り出す必要があります。
もう一方の運用テスト（ＯＴ）では、カットオーバー後に使用する本番コンピュータ機器の上で、本物のデータベースを使い、本物の取引を打鍵して、コンピュータの運用が可能かどうかを確認します。
予定したレスポンスが得られ、計画通りの処理量をこなせるかを判断します。
バッチ処理では、予定の時間までに出力を出せるかを検証する必要があります。
以上のことを行うには、レガシー・システム（既存システム）の過去の本番データベースと、そこに入力された取引を事前に確保しておかなければなりません。
データ移行システムを使用することによって、この本番データベースを新システムのデータベースへと変換し、用意しておいた取引を打鍵します。
このようにするのは、確保されたデータベースと同じ日に入力された取引でないと、システムは動かないからです。
運用テストも、テスト基準日を進めていく形で行われます。
取引量がピークとなる日や、特殊な処理が発生する日がテスト基準日として運ばれます。
５２週農業生産工程管理システムでは、ピーク日、月末、月初、滞納締め日、売上代金支払日などを選択すればよいでしょう。
