運用テストは何をするのか？実施する意味についても紹介
はじめに
ITシステムの開発は様々な工程を経て本番稼働を迎えますが、その中には書類の作成、環境構築、プログラミング、テストといった作業等が含まれています。また開発を効率的に進めるための「開発モデル」はこれまでにいくつか提唱されていて、有名なものとしては
システム開発の基本的な工程
ITシステムの開発は、まず
「運用テスト」が開発工程の中でどういった役割を果たしているのかを理解するため、ウォーターフォールの各工程をさらに詳しく見ていきます。開発の第一段階としては、システムにどのような機能を持たせたいかをクライアントにヒアリングしながらエンジニアがまとめていき、要件定義書の作成が行われます。要件定義書に相違がないことを確認したら次に基本・詳細、外部・内部、プログラムと様々な設計書がそれぞれを担当するチームごとに作成されます。ウォーターフォールモデルではここまでの段階を「上流工程」と呼び、プロジェクトマネージャー・リーダー、SE、各チームのリーダーが中心となって進められます。続いてそれら設計書に基づいた環境構築やプログラミング等の開発作業が開始され、各開発段階ごとに数種類のテストが行われます。この実作業、テストの段階が上流工程に対して「下流工程」と呼ばれます。
なお、今回は主題から逸れるので詳しく紹介しませんが、その他の開発モデルとしては、これらウォーターフォールに似た工程を短期間の間に何度も細かく繰り返し、最終的に完成させるというスパイラルモデルや、開発単位を細かく分けたうえで各単位ごとにウォーターフォールのような工程を行うアジャイルモデル、先に試作品(プロトタイプ)を作成し、ユーザーとの認識を合わせながら進めるプロトタイプモデルといったものがあります。企業やプロジェクトによって利用するモデルに偏りがある可能性はありますが、今後様々な現場でエンジニアとして活躍したいと思っている方は、どの開発モデルにも対応できるエンジニアとなれるように詳しく調べてみることをおすすめします。
話を戻しますが、今回紹介する「運用テスト」はウォーターフォールモデルにおけるプログラミング等の開発作業と本番稼働の間に行われる数種類のテストのうちの一つとなります。
本番前に実施されるテストの種類
システム開発中に行われるテストは、主に「単体テスト」「結合テスト」「総合テスト」「運用テスト」の4つに分類されることが多いです。なおIT業界では「PMBOK（Project Management Body of Knowledge）」や「ITITファウンデーション」といったプロジェクトマネジメントに関する知識や、ITサービスマネジメントに関する基礎知識の集約は見られるものの、名称の標準化等が行われていないため、
まず「単体テスト」ではプログラム単位、モジュール単位での動作確認が行われます。そのため、該当機能の開発に携わったチーム内で行われるテストという面が強い段階です。単体テストが終わると次は「結合テスト」です。結合テストでは、単体テストをクリアした各プログラム・モジュールを組み合わせた状態で正常に動作するかを検証します。この段階もクリアすると次に行われるのは「総合テスト」となります。総合テストは開発システム全体を通してのテストとなり、これまでの工程の中で一番本番環境に近い状態での検証が行われ、各チーム協力してのテストやバグ改修が行われます。総合テストまでは基本的にエンジニア側だけで完了できるテストとなりますが、最後の「運用テスト」はメインで行うのがクライアント側となり、エンジニアと連携しながらテストを進めていくこととなります。
なお、各テスト工程において、プログラムの動作を確認する「単体テスト」「結合テスト」「総合テスト」の部分をホワイトボックステストと言い、「運用テスト」をブラックボックステストと呼び分けられることがあるということを頭の片隅に記憶しておきましょう。
運用テストでは何をする？
運用テストは本番稼働直前で行われるテストであり、この段階で発覚しなかったバグや不具合は当然ながらそのまま本番環境に反映されてしまうため、非常に重要な局面と言えます。また、運用テスト以前はエンジニア側で実施するテスト段階であるため、ある程度予測のつく前例あるエラーや不具合が発生することがほとんどですが、運用テストは、ITに精通していない人が含まれる可能性もあるクライアント側でのテストが行われます。また、IT知識があったとしても、普段現場で行われる操作は到底エンジニア側で全てを把握することはできないので、エンジニア側では予期していなかったエラーが発生することも十分考えられます。そういった観点からも運用テストは重要であり、かつ時間を要する可能性もある工程と言えます。そのため、運用テストは本番稼働の予定に支障が出ないようにクライアント側ともしっかり打ち合わせ行ったうえで、余裕を持ったスケジューリングをしておくことをおすすめします。
運用テストで行われる具体的な内容ですが、一つは当初作成した要件定義書や仕様書の通りの機能が実装されているかの確認があります。二つ目は想定通りの時間内で処理が実施されるか、高負荷が発生した場合どのような挙動をするかや、誤った処理を行った場合にどのような挙動をするかの確認です。三つ目は、クライアント側が新システムに慣れるための時間、正常に操作が行えるかの確認の時間です。以上の確認が運用テストの段階で同時に実施されます。
運用テストは誰が行うか？
ここまでも何度か紹介していますが、運用テストをメインで行うのはクライアント側となります。なお、クライアントはテスト項目の実施だけではなく、運用テスト仕様書、テスト項目の作成、また、テスト用データの用意等を行う必要も出てきます。一方のエンジニア側は、運用テスト計画書の作成、テスト用環境の構築、テスト用データのインポート、テストの付き添い等を行います。
運用テスト計画書では、テストの種類、範囲、実施方法・結果の判断方法、実施環境、使用ツール、実施スケジュールといった内容を策定します。運用テスト仕様書では、テストの具体的な内容や用語の定義、利用するテストデータについて策定します。なお、仕様書はクライアント側で作成することとなりますが、作成し慣れていないクライアントがほとんどであるため、あらかじめサンプルの仕様書を渡したり、参考資料等を提供したりとエンジニア側でサポートをしながら完成に導きます。テストの時間は限られているため、テスト項目としてクライアントから挙げられたものに関して実際にテストする必要があるか等の協議も行う必要がありますが、その際はあくまでもクライアント優先、ユーザー目線で行うことをおすすめします。これからシステムを利用するのはクライアントであり、業務フローや普段発生しがちなトラブルはクライアント側の方が熟知しているためです。対してエンジニアは自分達のスキルに沿った開発現場での常識の範囲でしかテスト項目を挙げられないという面があります。テクニカルな部分で不足している部分があった場合に、その点を補う等のサポート役に注力しましょう。また、クライアント側の担当者は遠慮することなくこの時点で懸念されることは出し切ってしまいましょう。
テスト用環境の構築はエンジニアが行いますが、この時までにクライアント側では、テスト用のデータを用意してエンジニアに渡しておく必要があることに注意が必要です。なお、本番環境を使ってテストが行われることもまれにありますが、基本的には本番とそっくりなテスト環境を別に用意する、あるいは、Webサーバー等一部を除いてテスト環境を構築してテストが行われることの方が多いです。テスト中に発生した不具合によって本番環境に致命的な不具合や故障を発生させてしまったり、テストデータと本番データが混じってしまったりという状況を発生させないためです。
テストの実施はクライアント側の特定の担当者個人、あるいは複数人で行うことが多いです。場合によってはこの時にエンジニア側の担当者が新システムの利用方法をレクチャーし、その中で発生した問題点を吸い上げることもあります。あらかじめ作成されたマニュアル通りの操作・挙動の検証を行う場にもなります。また、敢えて高負荷の発生するような状況を作って想定された挙動がされるかを確認することもあります。そのため監視ツールにアラートが上がることもあるので、事前に運用・保守をしているエンジニアに共有しておくとスムーズにことが運びます。クライアントから吸い上げたバグや不具合は必ず管理一覧表等で管理しておき、漏れがないよう改修の進捗を管理しましょう。全ての改修が確認できたら、いよいよ本番稼働となります。
まとめ
運用テストは単純なテスト作業でありながら、バグや不具合の検知・改修、ユーザー側のスキルアップ・システム把握、クライアントとの最終的な認識合わせといった様々な役割を持った工程となることがわかっていただけたことでしょう。それだけの