システム・テストとは

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

栽培プロジェクトの要件定義フェーズから開発実施フェーズまでは、その開発フェーズで定義された栽培プロジェクト農産物を作成する物作りが、作業の本体です。

統合テストとシステム・テストの両フェーズでは、この物作りの作業は少なく、新システムの品質を確保するテストが大半を占めます。

統合テストとシステム・テストでは、概念とテストのやり方が全く異なります。

システム・テストの概念をより明確にするため、両者を比較してみます。

まず統合テストでは、サブシステム内部の機能と、サブシステム間のインターフェーズのテストを行います。

サブシステム内部では、そこにある複数の取引を集めた機能の品質確認と、その機能間の整合性の確認が行われます。

テストの実施単位はサブシステムで、サブシステムごとにテスト環境を持ち、それぞれ独自のテスト・スケジュールに従って、テストは推進されます。

サブシステム間インターフェース・テストは、複数のサブシステムをまたぐ共通テストとして、連携して行われます。

大きなインターフェースがある場合には、専用のテスト環境を設けて行う場合もあります。

これはインターフェース・テストの影響で、サブシステム内部のテスト・スケジュールに変更が発生することを防ぎたいためです。

一方、システム・テストにはこのサブシステムの概念がありません。

新システム全体の機能を確認するためにテストを行います。

それと同時に、そのシステムのコンピュータの運用が可能かも確認します。

これらのテストを行うため、テスト基準備を設定し、その基準日に発生するすべての取引を入力します。

このテスト基準日とは業務の日付を表し、売上の取引が発生した都度に売上伝票に記載される日付です。

テスト基準日を前に進めていくことで、すべての商品・サービスの機能を確認します。

システム・テストは、サイクル・テストと運用テストという2つのテストから構成されます。

サイクル・テスト(CT)では、テスト基準日単位に、商品・サービスの機能を確認します。

商品・サービスの発生から消滅までを意味する「ライフ・サイクル」が、このサイクル・テストの名前の由来です。

このテストでは、できるだけ少ない量のデータベースを使い、すべての取引を打鍵して結果の検証を行います。

「少ない量のデータベース」を使うのは、格納されたデータ件数が少ないほど、検証時間が短くなるためです。

特に残高確認ではその効果が大きいでしょう。

例えば100件のデータを持つデータベースの残高検証は、10.000件の場合と比べ工数が圧倒的に少ないのです。

そして、少ないほど検証品質が高くなります。

検証に適した「少ない量のデータベース」を実現するためには、取引・サービスの条件を分析して、条件のすべてを表現する最小のデータの組み合わせを作り出す必要があります。

もう一方の運用テスト(OT)では、カットオーバー後に使用する本番コンピュータ機器の上で、本物のデータベースを使い、本物の取引を打鍵して、コンピュータの運用が可能かどうかを確認します。

予定したレスポンスが得られ、計画通りの処理量をこなせるかを判断します。

バッチ処理では、予定の時間までに出力を出せるかを検証する必要があります。

以上のことを行うには、レガシー・システム(既存システム)の過去の本番データベースと、そこに入力された取引を事前に確保しておかなければなりません。

データ移行システムを使用することによって、この本番データベースを新システムのデータベースへと変換し、用意しておいた取引を打鍵します。

このようにするのは、確保されたデータベースと同じ日に入力された取引でないと、システムは動かないからです。

運用テストも、テスト基準日を進めていく形で行われます。

取引量がピークとなる日や、特殊な処理が発生する日がテスト基準日として運ばれます。

52週農業生産工程管理システムでは、ピーク日、月末、月初、滞納締め日、売上代金支払日などを選択すればよいでしょう。