システム開発の現場で「次は受入テストです」と言われても、何を確認するのか分からない方も多いでしょう。
受入テストは、システムが利用者の仕事や目的に合っていて、利用開始や引き渡しへ進める状態かを判断するためのテストです。
この記事では、受入テストの目的や確認内容を、ネットショップの例で解説します。システムテストとの違いや、UATとの関係も初心者向けに整理します。
💡 このページでわかること
- 受入テストの意味と目的
- 受入テストとシステムテストの違い
- 受入テストを行う人と判断の基準
- 受入テストを行う時期
- UATと受入テストの関係
受入テストとは？
受入テストとは、システムが利用者の業務上の要望を満たし、利用開始や引き渡しへ進める状態かを判断するテストです。
たとえば、会社が商品の注文を管理するシステムを開発会社へ依頼したとします。
画面や機能が仕様書どおりに動いても、実際の仕事で使えるとは限りません。注文の受付から発送まで無理なく進められるか、担当者が必要な情報を確認できるかなど、利用者の仕事の流れに合っている必要があります。
そこで、利用者や発注者の立場から「業務上の目的を達成できるか」「受け入れてよい状態か」を確かめます。
受入テストを行う目的
主な目的は、システムを利用・導入できる状態か判断することです。
具体的には、次のような点を確かめます。
- 利用者の業務上の要望を満たしているか
- 実際の仕事の流れに沿って使えるか
- 必要な機能や情報がそろっているか
- 利用開始を妨げる問題がないか
- 利用開始、引き渡し、公開などへ進んでよいか
受入テストで不具合が見つかることもあります。ただし、不具合をできるだけ多く見つけることだけが目的ではありません。利用者の目的を達成できる状態かを確かめ、受け入れるか判断することが中心です。
誰が受入テストを行うのか
受入テストでは、システムを使う人や、受け入れる立場の人が重要な役割を担います。
注文管理システムなら、受注を処理する担当者や発送を管理する担当者などです。実際の業務を知っているため、「必要な情報が足りない」「この手順では仕事を進めにくい」といった問題に気づけます。
ただし、担当者だけでテストのすべてを進めるとは限りません。発注側の責任者、業務担当者、運用担当者、テスト担当者、開発者などが、準備や実施、結果の確認で協力する場合があります。
大切なのは担当者の肩書だけではありません。利用者の業務や受け入れ条件を基準に判断できる人が関わることです。
具体例｜ネットショップの注文で考えよう
ネットショップの注文管理システムを例に考えてみましょう。
このシステムでは、次のような仕事を行います。
- 購入者が商品を注文する
- 店舗担当者が注文内容を確認する
- 在庫数を更新する
- 発送の準備をする
- 購入者へ発送メールを送る
個々の画面が正しく動いていても、店舗担当者が仕事を最後まで進められなければ、業務で使える状態とはいえません。
そこで受入テストでは、たとえば次の流れを確認します。
- 購入者として商品を注文する
- 店舗担当者として注文を検索する
- 注文内容と配送先を確認する
- 発送済みの状態へ変更する
- 購入者へ発送メールが届くことを確認する
ここでは、ボタンが動くかだけを見ません。担当者が必要な情報を確認でき、注文受付から発送までの仕事を完了できるかを確かめます。
実際に起こる場面も確認する
通常の注文だけでなく、在庫切れ、注文の取り消し、配送先の変更など、業務で起こり得る場面も確認します。
このような一連の利用場面を「シナリオ」と呼ぶことがあります。ここでは「利用者が実際に行う仕事の流れ」と考えれば大丈夫です。
受入テストとシステムテストの違い
システムテストと受入テストは、どちらも完成に近いシステム全体を対象にすることがあります。違いを理解するには、担当者だけでなく、目的と判断基準を見ることが大切です。
| 比較項目 | システムテスト | 受入テスト |
|---|---|---|
| 主な目的 | システム全体の動作や能力を確認し、必要な品質を満たすか確かめる | 利用者の業務上の要望を満たし、利用開始などへ進める状態か確かめる |
| 主な判断基準 | システムの仕様や品質に関する条件 | 業務上の要望や、受け入れてよいと判断する条件 |
| 主な視点 | システム全体が必要な機能や性能を備えているか | 利用者がシステムを使って目的を達成できるか |
| 関わる人の例 | テスト担当者、開発側の担当者 | 利用者、発注者、業務担当者、運用担当者 |
| 確認の例 | 注文処理が正しく動くか、決められた時間内に処理できるか | 担当者が注文受付から発送までの仕事を完了できるか |
| 結果の使い方 | 品質上の問題を確認し、修正や次の段階へ進む判断に使う | 利用開始、引き渡し、公開などへ進む判断に使う |
簡単にまとめると、システムテストは「システム全体が必要な動作や品質を備えているか」、受入テストは「そのシステムで利用者が目的を達成でき、受け入れられるか」を主に確認します。
同じ機能でも見るポイントが違う
注文を検索する機能を例にすると、違いが分かりやすくなります。
システムテストでは、入力した注文番号に対応する注文が正しく表示されるか、決められた時間内に検索結果が表示されるかなどを確認します。
受入テストでは、担当者が普段持っている情報で注文を探せるか、仕事に必要な項目が表示されるか、次の作業へ進めるかなどを確認します。
確認する操作が重なることはありますが、目的と合否を判断する基準が異なります。どちらか一方で代用できるとは限りません。
受入テストでは何を確認する？
受入テストでは、事前に決めた要件や受け入れ基準に沿って確認します。
要件とは「システムに何を求めるか」をまとめたものです。受け入れ基準とは「どの状態なら受け入れてよいか」を判断できる具体的な条件です。
代表的な確認内容は次のとおりです。
- 必要な業務を最初から最後まで行えるか
- 利用者の要望に合った結果になるか
- 必要な情報を入力・確認できるか
- 利用者ごとに使える機能が正しく分けられているか
- 実際の利用を想定した件数や操作でも、業務に支障がないか
- マニュアルや運用手順に沿って使えるか
受け入れ基準は「注文を登録できる」のような曖昧な表現ではなく、満たしたかどうかを判断できる形にします。たとえば「必須項目を入力して注文を確定すると、注文番号が発行される」のように具体化します。
機能だけでなく仕事全体を見る
受入テストでは、画面やボタンだけでなく、システムを使った仕事全体を見ることが重要です。
注文登録が成功しても、発送担当者がその注文を見つけられなければ業務は止まります。また、画面上の処理が終わっても、必要な帳票を出せなければ仕事を完了できないことがあります。
「各機能が動いたから問題ない」で終わらせず、利用者が目的を達成できるところまで確認します。
受入テストはいつ行う？
順番に工程を進める開発では、一般に、システムテストなどを終えて受け入れ判断ができる状態になった後、利用開始や引き渡しの前に受入テストを行います。
代表的な流れは次のとおりです。
- 単体テストで、小さな部品や機能を確認する
- 結合テストで、部品や機能のつながりを確認する
- システムテストで、システム全体の動作や品質を確認する
- 受入テストで、業務上の要望を満たすか確認する
- 受け入れ可能なら、利用開始や引き渡しへ進む
ただし、これは代表例であり、すべての開発に当てはまる固定の順番ではありません。
必ず最後に一度だけ行うとは限らない
小さな単位で開発と確認を繰り返すプロジェクトでは、完成した機能や短い開発期間ごとに受け入れの確認をすることがあります。システムテストと受入テストの活動が、時期として一部重なる場合もあります。
また、受入テストの準備は実施直前に始めるとは限りません。何を満たせば受け入れられるかは、要件を決める段階から関係者で整理できます。
「多くの場合は利用開始前の判断に使うが、実施時期や回数は開発の進め方によって変わる」と覚えておきましょう。
UATは受入テストと同じ意味？
UATは「User Acceptance Testing」の略で、日本語では「ユーザー受入テスト」と呼ばれます。実際の利用者が、業務上の要望を満たすか確認する受入テストです。
現場では「受入テスト」という言葉をUATの意味で使うこともあります。しかし、厳密には、UATは受入テストの代表的な形の一つです。受入テスト全体と常に同じ意味とは限りません。
受入テストの代表的な形
- ユーザー受入テスト（UAT）：実際の利用者が、業務上の要望を満たすか確認する
- 運用受入テスト（OAT）：運用担当者が、バックアップ、復旧、利用者管理などを含めて運用できるか確認する
- 契約に基づく受入テスト：契約で決めた受け入れ条件を満たすか確認する
- 規制に基づく受入テスト：法律や規則など、守る必要がある条件に適合するか確認する
- アルファテスト・ベータテスト：正式公開前に、開発側の環境や限られた利用者による使用を通じて確認する
言葉の使い方は会社やプロジェクトによって異なります。「誰が、何を基準に、何の判断をするテストか」を確認すると、認識のずれを防げます。
受入テストでよくある疑問
受入テストでは不具合を探さないのですか？
受入テストでも不具合は見つかります。
ただし、主な目的は不具合をできるだけ多く探すことではなく、利用者の要望を満たし、受け入れられる状態かを確認することです。
開発者が受入テストをしてもよいですか？
開発者やテスト担当者が、環境やデータの準備、操作、問題の調査などを支援することはあります。
一方、受け入れてよいか判断するには、利用者の業務や発注者の要望を理解した人の関与が欠かせません。開発者だけで判断すると、実際の業務で必要なことを見落とす可能性があります。
受入テストに本番データを使いますか？
本番に近いデータを用意することはありますが、実際の個人情報や機密情報をそのまま使うと、情報漏えいの危険があります。
テスト用に作ったデータや、個人を特定できない形に加工したデータを使うなど、会社のルールに従って安全に進めます。
問題が見つかったら受け入れ不可ですか？
問題が1件でもあれば必ず受け入れ不可になるとは限りません。
起きたこと、操作手順、期待した結果、実際の結果を記録し、業務への影響と受け入れ基準に照らして判断します。修正後の再確認が必要か、利用開始を止めるほど重要かも関係者で決めます。
まとめ
受入テストとは、システムが利用者の業務上の要望を満たし、利用開始や引き渡しへ進める状態かを判断するテストです。
ポイントを振り返りましょう。
- 担当者だけでなく、目的と判断基準を見るとシステムテストとの違いが分かる
- システムテストはシステム全体の動作や品質、受入テストは業務上の要望と受け入れ条件を主な基準にする
- 個々の機能だけでなく、利用者の仕事の流れに沿って確認する
- 実施時期や回数は開発の進め方によって異なり、必ず最後に一度だけとは限らない
- UATは受入テストの代表的な形であり、受入テスト全体と常に同じ意味ではない
まずは「システムテストはシステム全体の動作や品質を確認し、受入テストはそのシステムで利用者が目的を達成でき、受け入れられるか判断する」と押さえておきましょう。