運用テストは顧客視点で行う最終テスト！工程の呼び方は実は様々です
「運用テスト」は、システム開発においていくつかあるテスト工程の中で、本番稼働直前、テスト工程の一番最後に行う確認テストのことです。
このテストが他のテストと大きく異なるところは、本番環境と同様の環境で（場合によっては、本番環境そのものを用いて）、実際の業務の流れに従い顧客が手を動かし、結果を確認するということです。
そして、「運用テスト」がテスト工程の一番最後に行うテストだ、という定義は変わりませんが、テストの名称や略称が、開発企業側の定義によって異なることがあるのです。
ここでは、「運用テスト」の概要を説明しながら、テスト工程における名称・略称の違いというIT業界の不思議な文化について、お話しようと思います。
目次
１．運用テストとはどんなテストか？
１-１．顧客視点で行う唯一のテスト
書き出しでも説明しましたが、運用テストが他のテストと大きく異なる点は、テストを実施する際の観点です。
通常、開発企業側が行うテストは、作成したプログラムが設計した通りの仕様で、問題なく動作するかを確認するためのものです。一方、運用テストにおける観点は、プログラムというサイズ感はまったく問題ではなく、顧客要件を満たした機能になっているかどうかという点に尽きます。
顧客にとって、システム中のプログラムがどう絡み合い、どう動いているかについては、まったく興味の範疇外であり、入力したデータに対して出力された結果が、判断基準のすべてなのです。
そういう意味では、運用テストは「ブラックボックステスト」に分類できるでしょう。また、運用テストは、顧客の業務担当者がシステムの操作や運用に慣れるための工程という一面もあります。
１-２．本番稼働前の最後の関所
そしてもう１点重要なのは、運用テストが、本番稼働前に行う最後のテストである、ということです。
ここで障害を見過ごしてしまった場合は、それを隠し持ったまま本番稼働してしまうという怖ろしい事態に陥ります。そのため、有りとあらゆるパターンを想定したシナリオを作成して、テストを行う必要があります。
１-３．運用テストの流れ
それでは、運用テストとは、どんな手順の流れで行われるテストなのでしょうか。
以下に、運用テストの流れの一例を、簡単にご説明します。詳細な手順については、顧客や開発企業によって異なる場合があるので、ここでの説明は割愛します。
(1) テスト計画書の作成
運用テスト全体の目的、対象範囲、実施方法、テスト体制、テスト環境、スケジュール、判定基準等をまとめたテスト計画書を作成し、顧客と合意します。
また、運用テストは本番環境とほぼ同等レベルで稼働しますので、プロジェクトメンバー全員に対しても、テスト計画書の内容を共有しておく必要があります。
(2) 運用テスト仕様書の作成
テスト計画書に基づき、運用テスト仕様書を作成します。運用テスト仕様書は、テストに必要なシナリオ、条件、確認すべき項目等を具体的に定義します。
ここで他のテストと大きく違うところは、運用テスト仕様書は、原則顧客が顧客側の観点で作成するということです。
また、テスト実施時に必要なテストデータの内容についても、ここで定義を行います。
(3) 運用テスト環境の構築
運用テストは、本番稼働前の最後のテストなので、テスト環境は、本番環境と同じ構成の環境を構築する必要があります。
運用テスト専用の環境を用意する場合もありますが、構築済の本番環境を利用する場合や、災対環境を利用する場合もあります。
(4) 運用テストの実施
(2)で作成した運用テスト仕様書に基づき、顧客側のテスト担当者が運用テストを実施します。
障害を検知した場合は、障害管理票を起票して、不具合の改修を開発企業側に依頼します。また、必要に応じて先行作成している(はずの)操作マニュアル等の改修も行います。
２．運用テスト以外のテストとは？
運用テストが、システム開発におけるテスト工程の最後のテストであることは、前章でご説明した通りです。
そして、運用テスト以外にもテスト工程にはいくつかのテストがあることは、みなさんもご存じのことかと思います。
ここでは、運用テストに至るまでに行う各テストについて、簡単にご説明します。
２-１．単体テスト
作成したプログラム一つ一つに対して、詳細設計書に記載された個別の機能、条件が、すべて設計通りに問題なく動くかを確認するためのテスト。
テスト単位がプログラム単体となるため、テスト対象プログラムの呼出元、呼出先のプログラムは、スタブやドライバーを使用します。
関連記事
２-２．結合テスト
単体テストが終了したプログラムを関係のあるユニットとして組み合わせ、特にインタフェース周りの機能について、問題なく動くかを確認するためのテスト。
「2-1. 単体テスト」でスタブやドライバーで補っていたところも、実際のプログラムを結合して動かすイメージ。
２-３．システムテスト
本番環境とほぼ同程度の環境を用いて、基本設計レベルの仕様を満たしているかを確認するためのテスト。
開発企業側が実施する最終確認テストと言っても過言ではありません。
３．IT業界の不思議な文化
1章、2章と、テスト工程の最後に行われるテストを「運用テスト」と記載して来ましたが、実は開発企業によって、まったく別の名前で呼ぶことがあります。ここでは、そんなIT業界の不思議な文化について、ご説明します。
３-１．開発工程の名前(略称)の呼び方が変わることがある
開発工程の名前や略称は、本来であれば、業界内で統一されていてもおかしくない基準です。
ですが、各開発企業の定義によって、テスト工程の名前や略称が変わってしまうことがあるのです。
主な開発工程の名前と略称のバリエーションについて、下表に一覧化してみました。（ウォーターフォール型の開発手法を前提としています。）
表を見てお気づきの方もいらっしゃるかと思いますが、違う工程にも関わらず、同じ名前の工程名や略称が使われています。これらは、もちろん別々の開発企業で使用されているものなので、ひとつの開発企業の中で工程名や略称が重複することはありません。
それにしたって、紛らわしいことには変わりありません。
すべては、各開発企業の定義を統一してこなかったことが原因であり、開発企業を跨いでプロジェクトを渡り歩くITエンジニアにとっては、厳重な注意が必要です。
開発企業を跨いでプロジェクトが変わる場合は、まず真っ先に開発工程の名称、略称を確認しましょう。そして、確認した結果、今まで使用していた名称、略称と異なっていたとしても、「そういうものだ」と潔く諦めましょう。
開発企業によって開発工程の名称や略称が異なるのは、IT業界の長年の文化なのですから。
関連記事
３-２．名前(略称)が変わっても変わらないこと
それはもちろん、テスト工程の順番です。
運用テストが、「OT」と呼ばれようが「受け入れテスト」と呼ばれようが、テスト工程における最終確認テストである、という立ち位置は、決して変わることはありません。
４．運用テスト実施の注意点
最後に、顧客側が行う運用テストを見守る、わたしたち開発者側における運用テストの注意点と心構えを２点申し上げます。
４-１．トンデモ条件上等！ – 顧客視点と開発者視点の違いとは
まずひとつめは、顧客視点で提示してくるテストパターンを開発者側の思い込みで判断しない、ということです。
ここで、運用テストにおける、わたしの経験談をひとつご紹介します。
顧客側が提示してきた異常系の運用テストの条件には、「システム終了時に、画面の終了ボタンではなく、PCの電源ボタンを押した場合の動作を確認する。」という項目がありました。それを目にしたわたしたち開発側は、「そんなトンデモ条件は有り得ないので、テストする必要ないのでは」と思いましたが、顧客側は断固としてその条件を譲りませんでした。
よくよく事情をお聞きしてみると、過去にオペレーターがそういう操作を実際に行ってしまい、大問題になったことがあったそうです。
その当時の操作マニュアルには、「画面の終了ボタンを押してシステムを終了させてから、PCの電源断をする」というシステム終了の詳細な手順が漏れていたため、何も知らないオペレーターは、電源断してもよいのだと思い込んだのです。そして、操作マニュアルからその手順が漏れていたのは、開発者側が「システムの終了ボタンを押す前に、電源断するわけがない」という思い込みがあったからです。
顧客側の視点と開発者側の視点とは、時にそれほどまで違うものなのです。
そういう意味でも、運用テストにおいて顧客側が自分たちの視点からテストパターンを抽出し、実際に操作しながら結果を確認することは、とても重要で意味のあることなのです。
４-２．最後の関所だからこそ「NG」指摘は大歓迎！
そしてふたつめは、本工程で検出される「NG」指摘（つまりは障害）を良かったと思うことです。
改めて運用テストの役割とは、何だと思いますか？
上記でも何度も申し上げているように、運用テストの役割とは、顧客側の視点から顧客要件の最終確認を行い、開発者側からは検知できない観点から障害を焙り出すことです。
とは言いつつも、正直な話、この時点で本当に障害が発生すると、顧客側から怒られることが多いですし、詳細な障害報告書の提出を求められる場合もあります。
また、本番さながらに監視システムが稼働している場合もあるため、下手をするとエラーアラートが関係各処に発報されるという嬉しくない事態が発生したりもします。
ですが、障害をこの段階まで検知できなかった事実については潔くお詫びをしつつも、心の中では大きくガッツポーズをしてもＯＫです。
だって、ここで発覚しなかったら、その障害を含んだまま本番稼働に至ってしまうわけなのですから。
水際の事故を直前で防げたのです。十分に喜んで良いことですし、テストとはそのためにあるのです。
但し、障害は障害ですから、ガッツポーズはこっそりとネ(笑)
５．さいごに
ここまで運用テストの概要と「IT業界の不思議な文化」について説明してきましたが、いかがだったでしょうか？
テスト工程の略称については、「単体テストはUTと呼ぶんだ」「いや、PTだ」と論争になる場合がたまにありますが、どちらも間違っているわけではなく、そもそも開発企業側の定義によって呼び方が異なるのです。
わたしが新卒時代（20数年前…？）からその文化は変わることなく今に至っているので、今後もIT業界全体で統一される可能性はかなり低いでしょう。
ITエンジニアの働き方はいろいろで、ひとつの顧客の元で長く働く人もいれば、いろいろな顧客、いろいろな開発企業を渡り歩く人もいます。
特に後者の働き方で、開発業務に携わる人は、この「IT業界の不思議な文化」については、「そういうものだ」と柔軟性を持って対応するように心がけましょう。
「郷に入っては郷に従え」
昔の人はうまいこと言ったものです、その通りです(笑)
コメント