運用テストとは?
運用テストとは英語で「OT(Operations Test)」とも呼ばれ、多くのステップを経て進められてきたシステム開発の、まさに最終のテストです。システム開発の工程ではさまざまなテストが行われますが、運用テストはそれらのテストとどう違うのか、どんな内容で行われるのかを詳しく解説します。
本番稼働直前に行う最後の関門
ソフトウェアテストは、単体テスト・結合テスト、さらにシステム全体を稼働させて行うシステムテストの順に進められます。これらは通常、ベンダー側によって行われる動作チェックです。一方運用テストは、ユーザー側がこれらのテストの後に実施する本番稼働直前の最後の関門となるテストです。
テストを行うのはユーザー側
運用テストが他のテストと根本的に違うのは、本番稼働後と同様の環境下でエンドユーザーが行うテストであるということです。実際の運用環境で行うことも少なくないようです。
ユーザー側の視点でシステムの動作チェックを行うため、「ベンダー側が想定していなかった操作をしてどういう結果が出るか」といった点についても検証します。
例えば「システムを終了させず電源ボタンを押す」、「データを保存せずにサービスを終了させる」といった操作です。また、UI(ユーザーインターフェース)など、使用上の不都合がないかといった観点からの確認も行います。
また運用テストは、ユーザー側の担当者がシステムの操作や運用に習熟するための場でもあります。テストを行うのはあくまでユーザー側ですが、ベンダー側も協力してテストの進行を支援します。
運用テストの目的
運用のテストの目的は、ユーザー側が実際の業務でシステムを問題なく利用できるかどうかを確かめることです。そのため、運用のテストの主体はユーザー側にあり、ベンダー側はユーザーと密に連携しながら運用テストを進める必要があります。
具体的には、システムの開発当初に定めた要件が守られているか・品質が保たれているか等をチェックします。また、システムの使い方をユーザーに教育するといった目的も含みます。
システム開発におけるその他のテストを簡単に解説
システム開発におけるテストは、大きく分けてプログラムの動作を確認するホワイトボックステストと、システムの仕様を確認するブラックボックステストがあります。運用テストは後者のブラックボックステストに分類されます。以下で、各テストの概要について説明します。
・単体テスト(Unit Test/略称UT)・・・作成したプログラムのひとつひとつをモジュール単位で動作を確認・検証するテスト。不具合が見つかった場合には修正し、最終的に問題がないことが実証されたあとで結合テストへ移行します。
・結合テスト(Integration Test/略称IT)・・・単体テストが終了したモジュールを結合させた状態で、動作の確認や入出力の検査などを行うテスト。主にモジュール間のインターフェースが正しく機能するかを確認し、問題がないことが実証されたあとで総合テストへ移行します。
・システムテスト(System Test/略称ST)・・・本番に近い環境を用意し、システム全体を稼働させた上で動作確認などを行うテスト。ベンダー側による最終確認テスト、総合テストという場合もあります。
・運用テスト(Operation Test/略称OT)・・・システム開発における最終テスト。本番稼働後と同様の環境(または実際の運用環境)でユーザー側が動作確認等を行います。ベンダー側も協力しテストの進行を支援します。
運用テストの進め方
それではもう少し具体的に、運用テストをどう進めていくのかを紹介します。運用テストで確認したいのはシステムの本番稼働後に支障なく業務で使えるかどうかなので、基本的には要件定義の際に確認した業務の流れに沿って操作し、動作を確認することになります。
ただし、要件定義書を遵守するというより、あくまで実際の業務の流れに沿ってテストシナリオを作成し、テストをするというイメージです。そうすることにより、要件定義書の記載漏れや間違いを発見することにもつながるからです。
運用テストの進め方としては、以下のとおりです。
テスト計画の作成
まずはテストの種類や範囲、実施の方法、実施環境、使用するツール、スケジュール、結果の判定基準などをまとめ、計画を策定します。内容についてはユーザー側と合意するとともに、ベンダー側の開発プロジェクトメンバー全員で共有します。
運用テスト仕様書の作成
次に、策定したテスト計画に基づいて運用テスト仕様書を作成します。内容としてはテストのシナリオや内容、確認すべき項目などの具体的な定義ですが、どのようなテストデータを使うのかということもここで決めます。仕様書は計画書と呼ばれる場合もあります。
運用テスト仕様書は基本的にユーザー側で作成しますが、どのように作成したらいいかわからないというケースもあるでしょう。そういう場合はベンダー側で必要な資料を提供する・テンプレートを準備するなど、作成のサポートをするとよいでしょう。
運用テスト仕様書の記載項目例
▪テスト概要 詳細なテストシナリオを作成する前に、まずここでどういったテストをしようとしているのかという概要を記載します。
▪テストシナリオ どんな業務をどうテストするのか、どのようなデータを使用するか、極力具体的に記載します。運用テストの環境構築やデータ提供はベンダー側が行うことになるため、テストシナリオはきちんとベンダー側と共有しましょう。
▪テスト実施担当者 誰がテストを実施するかを定めます。原則としてシステムの利用部門の担当者となります。
▪テスト結果確認者 テスト結果を確認する人、利用部門の責任者、または担当者の上司となる場合が多いです。
▪テスト体制 テストを実施する体制を記載します。ユーザー側がテストを実施し、ベンダー側は支援となることを確認します。
▪テストスケジュール 運用テストのスケジュールを立てて記載します。
テスト環境の構築
運用テスト仕様書が作成されたら、ベンダー側で運用テストの環境を構築します。本番稼働前の最後のテストとなりますので、テスト環境は本番環境と同じ構成の専用環境を構築したり、場合によっては災害環境を利用したりすることもあります。
▪運用テスト専用環境を構築するケース 本番環境とできるだけ条件を揃えて、運用テストの専用環境を用意します。その環境でシステムの動作確認を行い、本番環境に移行した時に不具合が起こることのないようテストします。
▪本番環境を利用するケース 可能であれば、すでに構築されている本番環境を利用する場合もあります。ただし、開発中のシステムに不具合があると既存のプログラムやデータなどに悪影響を及ぼす危険性がありますので、それ以前の段階で必ず検証のための環境で動作確認を行いましょう。
▪災対環境を利用するケース 災害対策のための代替環境として用意する災害対策環境を利用して、運用テストを行う場合もあります。コストの削減ができ、また本番環境に影響を与えることなく運用テストを実施することができます。
テスト実施
ここまでの準備が整ったら、運用テスト仕様書に基づいてユーザー側のテスト担当者が運用テストを実施します。障害を検知した場合は、障害管理票を起こしてベンダー側に不具合の改修を依頼し、改修されるまで管理します。
テストの実施においては、仕様書にない作業は行うことのないよう注意が必要です。不用意に設定を変えると、システムの正常な稼働に影響が出ます。仕様書に記載のないことを行ったり、変更したりする場合、まず上司や責任者に必ず相談してもらいましょう。
操作マニュアルへの反映
システムの本番稼働後の運用にあたって、システムの維持管理運用、実際に業務を行うためのものなど、さまざまなマニュアルが作成されます。例えば維持管理運用のためのマニュアルでは、サーバーの起動や停止にはじまりシステムの運用にあたる担当者が何をすべきか、作業手順が詳細に書かれています。
その他、業務用のマニュアルには、業務でシステムを利用するユーザーの担当者が実際に操作するための手順などが記載されています。運用テストに先行してそうしたマニュアル類が作成されている場合には、運用テストの結果を踏まえ必要に応じて内容の改修を行います。
運用テストの注意ポイント
ここまで、運用テストの準備と実施について解説しました。では運用テストを実施するにあたって、どのようなことに注意する必要があるのでしょうか。
スケジュールには余裕を持たせる
運用テストはシステム開発において最後に実施される工程なので、遅れが生じるとユーザー教育の日程に影響したり、納期の遅れにつながったりする恐れがあります。不具合が検知された場合の改修期間も見越して余裕のあるスケジュールを作成し、ユーザー側・ベンダー側双方で共有しましょう。
徹底したユーザー目線で行う
要件定義にはじまるシステム開発の長い工程を、ユーザー側と密にコミュニケーションしながら進めていると、ベンダー側もユーザー側の意図や思いを完全に理解できたような気になるかもしれません。しかし、それは大きな誤りです。
ユーザー側の意図や思いを100%理解し合うのはまずあり得ないことですので、運用テストにおいては必ずユーザー側が自らの視点でテストパターンを作成し、テストを実施しましょう。
前述したように、ベンダー側からすれば「とんでもない」と思えるような想定外なことも含めて、実際にテストし検証することを徹底しましょう。
不具合・バグなどの報告は迅速に行う
当然ながら、運用テストにおいて何らかの問題点が明らかになる場合があります。それらはテストのあと定例ミーティングなどの場でまとめて報告を受けるのでなく、その都度ユーザー側に共有してもらいましょう。
改修に時間を要するような問題点の報告が遅くなると、納期に影響を及ぼす可能性もまた大きくなります。問題点などないに越したことはありませんが、いざ発覚しても本番稼働前に発見されたことを前向きに捉え、スピーディに調査や対応にあたりましょう。
別のテスト名で呼ばれることもある
IT業界では開発工程の名称が統一されておらず、テストの名称も会社によってまちまちであることも少なくありません。
システム開発の最終テストである運用テストについても、会社によって受け入れテスト(User Acceptance Test/略称UAT)、システムテスト(System Test/略称ST)などと呼ばれているケースがあります。テストなどでよく意味のわからない名称があった場合には、必ず周囲に確認しましょう。
本番環境を運用テストで使う場合は要注意
運用テストをユーザーの本番環境(実際の業務で使用している環境)で実施する際は、十分に注意が必要です。システムにバグが残っていたり予期せぬトラブルが発生したりした場合、ユーザー側の重要なデータや機器に支障が出る恐れがあります。
そのため、ネットワーク・データ・セキュリティ設定・ハードウェア等のインフラが本番環境と同等の環境を別で用意すると安心です。
運用テストはエンジニアとしてスキルアップにつながる
運用テストの目的や内容、注意ポイントなどついて紹介しましたが、いかがでしたでしょうか。運用テストは本番稼働前の最終テストのため、ユーザー側は業務手順や操作性など、幅広く確認しなければなりません。
スムーズにテストを進行するためには、システムのすべてを把握したベンダー側のサポートが欠かせません。
またエンジニアとして運用テストに関わることは、納品に至る開発全体の流れを理解できることになります。テストの技法やノウハウが身につき、テストエンジニア、システムエンジニアとしてのキャリアアップにもつながるいい経験となるでしょう。
編集部オススメコンテンツ
アンドエンジニアへの取材依頼、情報提供などはこちらから