システム開発における開発工程の一部である受入テストについて具体的にどのようなことをしているのか、どのように進めたら良いのか、よく比較されがちな結合テストやシステム（総合）テスト、運用テストと何が違うのか、その辺りも含めて解説していきます。
本記事を読んでいただき、システム開発における受入テストについて、少しでも理解を深めていただけると幸いです。
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 |
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個変えると他にも影響が出てくるケースも多く、単純作業で終わるモノではないと認識しておきましょう。
「受入テストとは」まとめ
システム開発における受入テストについて解説してきました。受入テストは、基本的にクライアント側で行うテストとなります。これまでは開発者側で実施してきたテストですが、クライアント側の最終チェックが入ります。実質最後のテストです。受入テストをクリアして初めてリリースの準備に進めることになります。
- 「受入テストを自動化して業務効率化したい…」
- 「テスト工程だけでも外部委託を検討しているが、切り出しでお願いできるものか…」
- 「そもそも受入テストやったことなくて、何をやれば良いか分からない…」
こんなお悩みありませんか…
弊社はお客様に合わせて様々な体制を組むことが強みでもあり、オフショア開発、ニアショア開発、オンサイト（常駐型）開発、受託開発など…お客様の状況に合わせてご提案いたします。相談は無料！なのでお気軽にお問い合わせください。