運用テスト

運用テストは、システム開発V字モデルで、要件定義に対応するテストにあたります。

要件定義は、「業務を効率化したい」とか「新たな業務モデルを実現したい」といった業務を改善するための要求から、コンピュータシステムとして実装すべき部分をシステム化への要求機能として定義する工程です。この工程で作成される「要件定義書」は、ユーザのシステムに対する要求をシステムベンダーがヒアリングしてシステム要求としてまとめる形となりますが、作成責任としてはシステムベンダー側にあるものの、承認責任はユーザ側にあり、ユーザ側の責任度合は非常に高いものです。

システムベンダーは「要件定義書」の内容を基にシステム開発の正式見積を行ない、「要件定義書」に記載された機能要求の実現の対する請負契約を締結します。システムとして実装される機能は、要件定義として決定した範囲内ということになります。

運用テストの位置づけ

運用テストは、本番稼働する前段階のテストと位置づけられるもので、本稼働の可否を判断するためのテストとなります。

一般的にはユーザが主体となって実施されるテストと考えられていますが、現実的にはユーザ主体でのテスト実施は難しいものがあります。ユーザにはコンピュータシステムに対する知見は少ないですし、通常業務と並行して運用テストを実行するのは多大な負荷がかかる作業です。
しかし、実稼働で問題が発生してしまうと、ユーザの業務が停止するだけでなく、ユーザの取引先にも影響する事態になりかねません。問題発生により損害が生じた場合には、その負担をめぐって訴訟に発展する可能性もあります。

そこで、運用テストにおける実作業をユーザとシステムベンダーが分担するスタイルが効果的とみられるようになっています。

運用テストのチェックポイント

ユーザとシステムベンダーが協力して運用テストを実施する場合、それぞれに検証の対象を定義しておくと無駄なく効率的に実施することができます。

日常業務が多忙と考えられるユーザは、運用テストで確認すべき要件定義事項の最終的な判定者とし、システムベンダーによる運用テストを先行します。

システムベンダーによる運用テスト

システムベンダーは、社内で基本設計に基づいた総合テストを実施し、そこで発覚した問題点を全て解消させています。

ただし、ユーザにハードウェアを新規導入するのであれば、そのハードウェアを社内に設置することで、ユーザの本稼働状態とほぼ同等な環境を用意することができますが、既導入済システムに追加改修する場合では、ユーザの実環境と同等なマシン環境を用意するのはなかなか難しいことです。
特に、無線接続された倉庫の移動コンテナに付けられたICタグリーダーなどといった機器を利用する場合、現場でないと有効な動作確認ができないケースもあります。

そこで、「実環境による総合テスト」といった意味合いで運用テストを実施することは、価値のある作業といえます。

システムベンダーによる運用テストでは、ユーザ環境でしか評価できないテストケースを計画して実施します。それは、特殊な機器による動作確認だけでなく、無線環境などトラフィックに関わるレスポンスタイムなど非機能要件の検証も含まれます。

「要件定義書」で定義されたシステム要求に対し、システムベンダーとして保証すべき要件に対する検証を行ないます。

ユーザによる運用テスト

本稼働をしてもいいかの判定をするためのテストであり、責任重大な作業です。テストに不備があると、稼働後に不具合等でシステムを運用できなくなることとなり、業務の停止や手戻りが発生することとなります。

しかし、ユーザはプログラムなどコンピュータに対する知識や経験は無く、効率的に運用テストを実行できるスキルも有していません。今回のシステム導入にあたり追加や変更が生じている部分と、それに対してどのような検証を行なえばいいのか、という情報をシステムベンダーから提示してもらうことで、テスト内容の不備を防止することができ、最低限実施すべきテスト内容を押さえることが可能となります。

ユーザによる運用テストでは、テストの対象や範囲についてシステムベンダーから情報を入手することから始まり、テスト設計された内容もシステムベンダーにもレビューをしてもらった上でテストを実施すると、テスト内容の過不足を排除することができ、テスト品質を高めることになります。

ただ、テスト結果の分析と評価はユーザ自らが行ない、本稼働判定可否を判断してください。

 ブログランキング・にほんブログ村へ

シェアする

  • このエントリーをはてなブックマークに追加

フォローする