システム開発における運用テストとは？発注者が把握すべき点や影響範囲について

運用テストとは、システム開発の下流工程において実施されるテストであり、システム開発の最終段階の納品前に行われます。このテストはシステムを実際に運用する環境もしくは同等の環境において行われます。この記事では運用テストの概要や確認すべきポイントなどについて解説します。

 

1.システム開発の過程で行われるテストの種類と役割　

システム開発の過程で行われるテストは以下の4つのテストがあります。

1.単体テスト

単体テストとは、システム内の個々のモジュール※1やコンポーネント※2を個別にテストすることであり、その目的は個々のモジュールやコンポーネントが設計通りに動作し、正しく機能するかの確認です。

 

2.結合テスト

結合テストとは、単体テストが完了した複数のモジュールやコンポーネントが組み合わさり、結合した際に、設計通りに動作するか検証するためのテストです。

複数のモジュールやコンポーネント間のインターフェース※3やデータのやり取りや連携などについて確認します。結合テストはシステムの品質を確保するために不可欠です。このテストが不十分だと異なるコンポーネント間で不具合が発生し、ユーザーがエラーや予期せぬ挙動に直面する可能性があります。結合テストはこのような問題を早期に発見し、リリース前に修正するための重要な工程となります。

3.運用テスト

運用テストとは想定された運用環境や使用条件・負荷のもとでシステムが正常に機能し、要件を満たすことの確認を行うことです。またシステム全体としての性能や安定性が確保されているかを検証を行います。さらに運用テストでは「ベンダー側が想定していなかった操作をユーザーが行った場合、どのような結果が出るか」といった点についても検証します。

運用テストはシステムテストやUTA（User Acceptance Test）、OT（Operations Test）、承認テストといった呼ばれ方をすることもあります。運用テストでは必要に応じて、運用マニュアルとの整合性なども確認し、実際の業務運用に支障がないかをチェックします。

4.受け入れテスト

受け入れテストとは、ユーザーが開発されたシステムを使用して、要件や期待に沿った動作を確認するため実装前に行うテストです。具体的にはユーザビリティテスト、ユーザーインタフェース、ユーザーが実際の業務をシステム上で行うシナリオのテストを行います。

類似記事は、知っておきたい！単体テストとはをあわせてご覧ください。

 

2.運用テストはいつ、誰によって行われるか　

単体テストや結合テストでは主に開発側が主体となって実施されますが、運用テストは発注者側やユーザーが主体になって実施されることが特徴です。
この章では「運用テストが誰によって行われるのか」「開発の流れのどこで実施されるのか」について説明します。

a.運用テストは発注者によって行われる

運用テストは開発者側が責任を持ち、ユーザー側の担当者が進めていきます。

運用テストではユーザー側から運用担当者を派遣して、運用担当者のトレーニングや教育を並行して行うこともあります。運用テストは実際の運用環境もしくは同等の環境において、実際の運用に耐えうるシステムか検証するために実施されます。

b.開発のフローのどこで実施されるか

運用テストは、システム開発の最終段階で行われます。

具体的には結合テストの完了後、本番稼働の直前に実施する工程です。運用テストで不具合やバグが発覚しなかった場合はそのままのシステムが本番環境に反映されてしまうため、極めて重要なテストです。

 

3.発注者はどこまで分かっている必要があるか

運用テストは発注者側が主体となり責任を持って行いますが、実際のテストの実施自体は外注先に一任して問題ありません。その際、外注先はユーザー側の立場に立ってテストの計画を立案し、実施をすることが求められます。また、レアケースの業務や例外業務、異常対応業務など、さまざまなテストシナリオを用意しユーザー環境に合わせたテストパターンを複数定義して行います。

運用テストはシステム全体としての性能、機能、信頼性が確保されているかを評価するテストです。そのため発注者である発注者への確認項目が多くなる場合があります。外注先はあらかじめどのくらいの確認頻度が想定されるかを発注者とすり合わせておくとよいでしょう。

また、発注者は、運用テストが納品前の最終段階のテストであることを理解し、このテストで不具合やバグを出し切る認識が必要です。
システムのユーザーは、時として予想外の操作や例外処理を行うことがあります。こうした点を認識しテストシナリオに含めておくことをおすすめします。開発者側にとってあたりまえの操作がユーザー側ではそうでないケースがあるからです。また、運用テストに際してはユーザー側の視点と開発者側の視点は大きく異なるため、開発者側は思い込みを外した方が良いでしょう。

運用テストは実際の業務の運用を想定した手順で行うので、業務フローやテストパターンなどは発注者しか知らない情報も多いため、テスト項目については発注者も責任を持ってチェックが必要になることは双方でしっかり理解しておくようにしましょう。

 

4.よくある運用テストで発覚する設計ミス　

運用テストが失敗すると実際の運用に対する影響が大きくなります。このテストはユーザー側の視点で行い、開発者側から検知できない観点で障害をあぶり出すことです。「エンジニアの想定外の操作がされた場合、どのような結果が出るのか」を考えて行う必要があります。

a.よくある設計ミス

想定通りの時間内に処理が完了しない場合や、高負荷な処理や、誤った処理が行われた場合にシステムに異常な挙動が発生する場合があります。また、先述のようにシステムのユーザーは必ずしもITに精通しているとは限りません。予期せぬエラーや不具合が発生することも十分考えられます。例えばユーザーが、システム終了時に、アプリケーションの終了ボタンではなく、PCの電源ボタンを直接押してしまうようなケースもありえます。エンジニアの想定外の処理が設計に反映されていないこともありえます。

b.ミスを生み出さない工夫

ユーザーの想定外の操作などによる不具合を回避するためには、あらかじめ要件定義や基本設計の段階で漏れなく洗い出しておくことが必要です。システム開発の担当者は現場のオペレーションのすべてを深く理解しているとは限りません。現場で日々、オペレーションしている担当者が業務プロセスや利用しているシステムの良し悪しを最も深く理解していることが多くあるため、MECE（漏れなくダブりなく）を意識してヒアリングを行うことが大切です。

また、運用テスト時には本番環境への影響を避けるために本番環境と同等なテスト環境を別で構築して行うとよいでしょう。可能であれば本番環境とオフラインの環境を準備することで、本番環境に致命的な不具合を発生させてしまったり、テストデータで本番データを上書きしてしまったりといったリスクを軽減できます。

c.ミスが起きてしまった際の対応

ミスや不具合が起きてしまった場合の対応について説明します。まず吸い上げた不具合やバグは必ず管理一覧表等で管理しておき、漏れがないように管理しましょう。不具合は開発者側に修正を依頼し改修されるまで進捗と結果を管理します。

特に開発をチーム（複数のメンバー）で行っている場合は、その対応が誰によって行われているか、解消までにどの程度時間を要するかを共有できていると良いです。

運用テストの段階ではシステムのリリースまでスケジュールが迫っていることが多いでしょう。不具合の重みによってトリアージ※4を行い、影響の大きいものや重要度の高いものから優先順位をつけて対応することが必要です。

 

5.まとめ

運用テストは単体や結合テストではカバーしきれない、システム全体の挙動や外部システムとの連携、セキュリティ、負荷状態での性能などの要素を検証するテストです。ユーザーを意識し、より広い視野で様々なパターンのテストを行うことで成果物の品質も向上します。

本コラムでは運用テストのポイントについて解説しました。情シスナビでは、本コラム以外にも、情報システムの開発に関わるさまざまなコンテンツを提供しています。是非確認してみてください。