あなたは、システム開発における開発工程についてどのような流れで開発が進んでいくのか気になっているところではないでしょうか。システム開発を外注にあたって、システムがリリースするまでの全体の流れを把握しておくことは重要です。
どのような流れでシステムは出来上がるのか、システム開発会社として25年経つ会社に所属している私が解説します。
本記事を読んでいただき、システム開発の全体流れを把握する1つの材料になればと思います。
1.運用テストとは？
単体テスト → 結合テスト → システムテストを一通りクリアしたら、テストの最終関門である運用テストを実施します。そんな運用テストについて、1章ではどのようなテストをするのか概要を説明します。
1-1.運用テストは、クライアントが実環境でテストすること
単体テスト→結合テスト→システムテストは開発者（ベンダー）側が対応してきたフェーズに対して、運用テストはクライアント（ユーザー）側が実環境でテストすることを指します。ユーザー側の視点でテストしてみて、ベンダー側が気づかなかった点を洗い出すことになります。
1-2.運用テストはテスト工程で最後に位置する
ここまで数多くのテストを実施してきましたが、運用テストは最後の砦になります。このテストをクリアしてようやくリリースまでたどり着けることになります。
各工程を以下のように略して呼ぶこともあるので、ここで覚えておくと良いでしょう。
工程 | 略称 | |
RD | Requirement Definition | |
BD | Basic Design | |
DD | Detail Design | |
UT | Unit Test | |
IT | Integration Test | |
ST | System Test | |
OT | Operation Test |
システム全体の流れについては以下の記事で紹介していますので、ご参考ください。
「システム開発の開発工程とは？10個のフェーズに分けて解説」
1-3.受入テストとの違い
運用テストとよく比較されるのが受入テストです。上記の図には受入テストという工程は入ってないですが、、受入テストとは何でしょうか。
実は、運用テストと受入テストは言葉が異なるだけ同じテスト工程のことを指しています。会社やプロジェクト、人によって呼び方が異なるので環境に合わせて言葉を選択するようにしましょう。
2.運用テストは誰がやるのか
運用テストの前のテストであるシステムテスト（総合テスト）は開発者側の最後のテストフェーズとなっています。開発者側のテストを全てクリアした状態で運用テストに進めることになります。
基本的には、運用テストのための運用テスト仕様書の作成からクライアント側が実施することになります。ただし、クライアントがITのことが詳しくないと何をしたら良いのか分からないこともあります。そのようなときは、開発者側から仕様書のテンプレートやどのような点についてテストするべきなのか、提供してあげましょう。（運用テストはクライアントがやることだからといって、クライアントに丸投げすることは避けましょう。）
※運用テストのテスト環境作りは開発者側で用意する必要があります。
3.運用テストの進め方
運用テストについて何となくわかったところで、3章では実際に運用テストの進め方を解説します。
3-1.運用テストの仕様書を作成する
運用テストを実施する前に仕様書を作成して、どのような項目をどのようにテストして結果はどのようにまとめるか等を統一します。仕様書を作成せずに進めてしまうと統一感のないテストとなってしまい、二度手間になるので情報統一のためにも仕様書は必ず作成しましょう。
運用テストまでのテストは開発者側が実施してきたので、仕様書は開発者側が作成してきましたが、運用テストはクライアントが実施するので、クライアントが仕様書を作成するケースが多いです。
＜仕様書に載せる項目例＞
- 運用テストのシナリオ
- 運用テストのスケジュール
- 運用テストの体制
- 運用テストの担当者 など
3-2.運用テストの環境構築
最後のテストになるので、実際の環境と同じ環境でテストできるようにします。テスト環境は開発者側が提供します。可能な限り本番環境でテストをするのが望ましいです。難しい場合は、本番環境に限りなく近い環境を構築して提供します。
念入りにやる場合は、バックアップ環境での運用テストも実施するケースもあります。
3-3.運用テストの実施
ここまでの準備が整ったら、準備したテスト環境で仕様書に基づいて運用テストを実施していきます。どのような観点でテストしたら良いかは、3章で具体的に紹介します。運用テストを実施して、結果を取りまとめます。
3-4.取扱説明書の作成
リリースまであと一歩のところまで来ました。運用テストが無事に完了したら当該システムを扱うための説明書を作成します。この説明書を基にユーザーはシステムを操作するので、図形や写真等を使って分かりやすく抜け漏れなく書く必要があります。
4.運用テストで見るべき観点
4章では運用テストにあたりどのような点に気を付けて進めるべきか解説します。
4-1.実際の運用（負荷）に耐えられるか
何人がどのような環境で同時接続するのか、想定して負荷テストをしましょう。想定している負荷よりもプラスαで負荷を掛けた方が安心できるでしょう。
4-2.ユーザビリティに優れているか
ユーザビリティに問題ないか確認します。開発者側では気づかなかったポイントがある可能性が高いです。UI/UXについて実際に操作することを想定しながらテストしていきましょう。
4-3.要件定義書通り動作するか
プロジェクトの最初に作成した要件定義書通りに動作するか確認していきます。
要件定義の詳細については、以下の記事に記載しています。
4-4.誤操作してもエラーが起きないか
不特定多数の人が扱うと自分が想定していない操作をする人もいるでしょう。「まさかこんなところクリックしないっしょ」と思いつつも、その操作をしてどのような挙動になるかテストする必要があります。
5.運用テストで失敗を避けるためのポイント
5章では運用テストの実施に当たって失敗を避けるために、押さえておきたいポイントを紹介します。
5-1.スケジュールには余裕を持たせる
運用テストはシステム開発において最後に実施される工程なので、遅れが生じるとクライアントの今後のスケジュールに直結で影響を受けやすいです。不具合が検知された場合の改修期間も見越して余裕のあるスケジュールを立てることをおススメしています。
5-2.ユーザー目線で行う
運用テストはユーザー側がするテストではありますが、テストする人以外の人が使うことも十分に想定されるでしょう。業務システムであればそれぞれの部署が使いたいがる操作を想定して確認すると良いでしょう。各部署の担当者1人ずつ選出して操作してもらうのが理想的ではあります。
絶対に操作しないような操作も確かめておくと良いですね。
5-3.不具合・バグなどの報告は迅速に行う
運用テストをやっている中で不具合や改善点は出てくるでしょう。その時は定例会で報告するのではなく、その場ですぐに報告するようにしましょう。システムの修正は一見簡単そうに見えても1個変えると他にも影響が出てくるケースも多く、単純作業で終わるモノではないと認識しておきましょう。
「運用テスト」まとめ
システム開発における運用テストについて解説してきました。運用テストは基本的にクライアント側で行うテストとなります。これまでは開発者側で実施してきたテストですが、クライアント側の最終チェックが入ります。実質最後のテストです。運用テストをクリアして初めてリリースの準備に進めることになります。
そんな運用テストについて記事をまとめましたが、弊社は会社を立ち上げたから25年が経ちます。長年の経験からシステム開発の手段について様々アドバイスできると思います。システム開発で行き詰った時には、どんな些細なことでも、お気軽にお問い合わせいただければと存じます。相談は無料！
