受入テストとは？目的・やり方・システムテストとの違いをわかりやすく解説

受入テストとは、かんたんに言うと「作ったシステムを、使う人が最後に確認するテスト」のことです。

システムとは、パソコンやスマホで使う仕組みのことです。たとえば、予約サイト、会員管理の画面、会社の注文管理システムなどがあります。

たとえば、新しい家ができたとき、住む人が「ドアは開くか」「水は出るか」「お願いした通りにできているか」を確認します。受入テストも、それに近い確認です。

ITでは、作ったシステムやアプリが、利用者の希望に合っているかを確認します。この記事では、受入テストの意味、目的、やり方、システムテストとの違いを初心者向けにわかりやすく解説します。

ほかのIT用語も知りたい方は、初心者向けのIT用語辞典もあわせてご覧ください。

受入テストとは

かんたんに言うと、使う人が最後に確認するテスト

受入テストとは、システムを使う人や、システムを依頼した側が行う確認です。

目的は、「お願いした内容どおりにできているか」「仕事で使える状態か」を見ることです。

ここでいう「使う人」とは、実際にそのシステムで仕事をする人です。たとえば、会社の注文システムなら、注文を受ける社員や、注文内容を確認する社員などです。

受入テストの英語はUAT

受入テストは、英語で「User Acceptance Test」と呼ばれます。

略して「UAT」と書くこともあります。Userは利用者、Acceptanceは受け入れ、Testはテストという意味です。

つまりUATとは、「利用者が受け入れてよいかを確認するテスト」のことです。

受入テストの目的

利用者の希望に合っているかを確認する

受入テストの目的は、利用者の希望に合っているかを確認することです。

画面が動くだけでは、十分とはいえません。使う人が求めていた仕事を、きちんと進められるかが大切です。

たとえば、注文システムなら、商品を選び、数を入れ、注文内容を確認し、注文を完了できるかを見ます。

仕事で使える状態かを確認する

受入テストでは、実際の仕事に近い流れで確認します。

ボタンを押せるかだけでなく、「社員が毎日の仕事で使えるか」「必要な情報を見られるか」も見ます。

機能とは、システムでできることです。たとえば、ログイン、検索、保存、印刷などがあります。

受入テストでは、こうした機能が仕事の流れに合っているかを確認します。

受入テストが使われる場面

新しいシステムを作ったとき

新しいシステムを作ったときは、使い始める前に受入テストを行います。

たとえば、予約システム、問い合わせフォーム、社内の管理システムなどです。

システム開発の全体の流れを知りたい場合は、システム開発に関係する人を整理しておくと理解しやすくなります。

システムを大きく直したとき

今あるシステムを大きく直したときにも、受入テストを行います。

画面を変えた場合や、新しい機能を追加した場合は、これまで通り仕事ができるかを確認します。

新しい機能を入れたことで、前から使っていた部分に影響が出ることもあります。そのため、大きな変更のあとには確認が大切です。

外部の会社に開発を依頼したとき

会社が外部の開発会社にシステムを作ってもらうことがあります。

開発会社とは、システムやアプリを作る会社のことです。

この場合、依頼した側が「この内容で受け取ってよいか」を確認するために、受入テストを行います。

受入テストは誰がやる？

基本は利用者側や発注側が確認する

受入テストは、基本的に利用者側や発注側が行います。

発注側とは、システムを作ってほしいと依頼した側のことです。

なぜなら、実際の仕事で使う人が確認しないと、「本当に使いやすいか」「仕事に合っているか」がわかりにくいからです。

開発会社は準備やサポートをすることが多い

開発会社は、受入テストの準備や説明を手伝うことがあります。

たとえば、テスト用の画面を用意したり、確認する項目を一緒に整理したりします。

ただし、最終的に「受け取ってよいか」を判断するのは、使う側や依頼した側です。

受入テストとシステムテストの違い

システムテストは作った側の確認

システムテストとは、作ったシステム全体が正しく動くかを確認するテストです。

多くの場合、開発会社や作った側が行います。

たとえば、ログインできるか、データを保存できるか、画面が正しく動くかを確認します。

受入テストは使う側の確認

受入テストは、使う側が「仕事で使えるか」を確認するテストです。

システムテストが「作ったものが動くか」を見るのに対し、受入テストは「利用者の目的に合っているか」を見ます。

項目	システムテスト	受入テスト
主に見る人	作った側	使う側・依頼した側
見る内容	システム全体が動くか	仕事で使えるか
目的	作った内容の確認	受け取ってよいかの判断

受入テストと総合テストの違い

総合テストは全体が動くかを見る

総合テストとは、システム全体をまとめて確認するテストです。

別々に作った機能を組み合わせたあと、全体として問題なく動くかを見ます。

たとえば、注文する画面、支払いの画面、確認メールを送る仕組みが、まとめて正しく動くかを確認します。

受入テストは業務で使えるかを見る

受入テストでは、実際の仕事に合っているかを見ます。

総合テストでシステム全体の動きが確認されていても、利用者の仕事に合っているかは別に確認が必要です。

そのため、総合テストと受入テストは似ていますが、見る立場と目的が違います。

受入テストと運用テストの違い

運用テストは本番と同じ流れで回せるかを見る

運用テストとは、システムを使い始める前に、実際の運用の流れで問題なく使えるかを確認するテストです。

運用とは、システムを日々使い続けることです。たとえば、データの確認、バックアップ、夜間の処理、困ったときの対応などがあります。

つまり運用テストは、本番が始まった後に初めて行うものではありません。使い始める前に、運用の準備ができているかを確認します。

受入テストは受け取ってよいかを判断する

受入テストは、システムを受け取ってよいかを判断するための確認です。

受入テストでは、求めていた機能や仕事の流れに合っているかを見ます。

どちらも本番前に行うことがありますが、見るところが違います。受入テストは「仕事で使えるか」、運用テストは「使い続ける流れを回せるか」を確認します。

テスト名	かんたんな意味	主に見ること
受入テスト	受け取ってよいかを確認する	機能や仕事の流れに合っているか
運用テスト	使い続ける準備ができているかを確認する	バックアップ、データ確認、トラブル時の対応など

受入テストの観点

受入テストの観点とは、何を見るかという確認の切り口です。

ただ画面をさわるだけではなく、仕事に必要なことを順番に確認します。

画面や操作が使いやすいか

画面の文字は見やすいか、ボタンはわかりやすいかを確認します。

使う人が迷わず操作できることは、とても大切です。

仕事の流れに合っているか

実際の仕事と同じ順番で操作できるかを確認します。

たとえば、注文を受ける、内容を確認する、発送の準備をする、といった流れです。

必要なデータが正しく出るか

入力した内容が、正しく保存されるかを確認します。

一覧表や帳票に、必要な情報が正しく出るかも大切です。

帳票とは、仕事で使う表や書類のことです。

間違った操作をしても困らないか

入力もれや入力まちがいがあったときに、わかりやすく知らせてくれるかを確認します。

たとえば、電話番号の入力もれがあれば、画面に「電話番号を入力してください」と出ると親切です。

受入テストの項目例

受入テストの項目は、システムの内容によって変わります。

ここでは、よくある確認項目の例を紹介します。

ログインできるか

決められたIDとパスワードでログインできるかを確認します。

また、使ってはいけない人が入れないことも確認します。

入力した内容が正しく保存されるか

画面に入れた内容が、正しく保存されるかを確認します。

たとえば、名前、住所、注文内容、金額などです。

必要な帳票や一覧が出せるか

仕事で使う一覧表や書類を出せるか確認します。

「売上の一覧を見たい」「注文の明細を出したい」など、仕事で必要な出力ができるかを見ます。

権限ごとに使える機能が分かれているか

権限とは、使える範囲のことです。

たとえば、一般の社員は見るだけ、管理者は登録や削除もできる、という分け方があります。

大切な情報を守るためにも、権限の確認は大切です。

受入テストのやり方

確認する内容を決める

まず、何を確認するかを決めます。

このとき、画面ごとではなく、実際の仕事の流れに合わせるとわかりやすくなります。

たとえば、「商品を登録する」「注文を受ける」「一覧で確認する」のように、使う場面ごとに整理します。

業務に近い流れで試す

次に、実際の仕事に近い流れでシステムを使ってみます。

予約システムなら、予約する、内容を変える、キャンセルする、予約一覧を見る、といった流れです。

いつもの仕事と同じように使ってみることで、気づきやすくなります。

結果を記録する

確認した結果は記録します。

「問題なし」「修正が必要」など、あとから見てもわかるように残します。

このような記録は、エビデンスとして残すことがあります。

問題があれば直してもう一度確認する

問題が見つかった場合は、内容を整理して開発側に伝えます。

不具合とは、思った通りに動かないことです。バグとは、システムの中にある間違いや不具合のことです。

直したあと、同じ問題が出ないかをもう一度確認します。

受入テストで作る主な資料

受入テスト計画書

受入テスト計画書とは、受入テストをどう進めるかをまとめた資料です。

いつ、誰が、何を確認するかを書きます。

計画書があると、確認もれを防ぎやすくなります。

受入テスト仕様書

受入テスト仕様書とは、具体的に何を確認するかを書いた資料です。

仕様書とは、確認する内容や条件を整理した書類のことです。

たとえば、「正しいIDとパスワードでログインできるか」などを書きます。

受入テスト結果報告書

受入テスト結果報告書とは、確認した結果をまとめた資料です。

問題がなかった項目、修正が必要な項目、再確認した結果などを書きます。

あとから見返せるように、わかりやすく残すことが大切です。

エビデンス

エビデンスとは、あとから確認できる記録や証拠のことです。

受入テストでは、画面の画像、操作した記録、確認結果のメモなどがエビデンスになります。

「いつ、何を、どう確認したか」がわかるように残します。

初心者が間違えやすい点

開発会社だけがやるテストだと思ってしまう

受入テストは、開発会社だけが行うものではありません。

使う側や依頼した側が、仕事で使えるかを確認することが大切です。

開発会社は準備を手伝うことがありますが、受け取るかどうかを判断するのは利用者側です。

細かいバグ探しだけが目的だと思ってしまう

受入テストは、細かいバグを探すだけの作業ではありません。

大切なのは、システムが仕事の流れに合っていて、使う人が目的を達成できるかを確認することです。

バグを見つけて直す作業については、デバッグの記事でくわしく説明しています。

システムテストと同じだと思ってしまう

受入テストとシステムテストは、どちらもシステムを確認する作業です。

ただし、見る立場が違います。システムテストは作った側、受入テストは使う側の確認です。

迷ったときは、「作った側の確認か、使う側の確認か」で分けると理解しやすいです。

運用テストを本番後の確認だと思ってしまう

運用テストは、本番が始まった後に行うテストではありません。

本番前に、バックアップやデータ確認、困ったときの対応などが回せるかを確認するテストです。

受入テストは「受け取ってよいか」、運用テストは「使い続ける準備ができているか」を見るものです。

受入テストに関するよくある質問

受入テストはいつ行いますか？

受入テストは、システムが完成し、実際に使い始める直前の段階で行います。

作った側がシステムテストなどを行い、大きな問題がなく安定して動くことを確認したあとに行うことが多いです。

受入テストはどこまで行えばよいですか？

受入テストでは、仕事でよく使う流れを中心に確認します。

すべての細かい動きを見るというより、使う人にとって大切な流れを確認することが大切です。

たとえば、注文システムなら「注文する」「内容を確認する」「注文を取り消す」などを優先して確認します。

受入テストでバグが出たらどうしますか？

バグが出たら、何をしたときに、どのような問題が起きたかを記録します。

そのうえで、開発側に伝え、直したあとにもう一度確認します。

問題を責めるためではなく、安心して使い始めるために確認します。

UATと受入テストは同じ意味ですか？

多くの場合、UATと受入テストは同じ意味で使われます。

UATは「User Acceptance Test」の略で、利用者が受け入れてよいかを確認するテストのことです。

ITパスポートでも受入テストは出ますか？

ITパスポートでは、システム開発やテストの流れに関する考え方が出ます。

試験対策として整理したい場合は、ITパスポートのマネジメント系もあわせて確認すると理解しやすくなります。

まとめ：受入テストとは、使う人が安心して受け取るための確認

受入テストとは、作ったシステムを使う人や依頼した側が、最後に確認するテストです。

かんたんに言うと、「このシステムを受け取って、仕事で使い始めてよいか」を見るための確認です。

システムテストは作った側の確認、受入テストは使う側の確認です。似ていますが、見る立場と目的が違います。

運用テストも本番前に行う確認ですが、見る内容が違います。受入テストは「仕事で使えるか」、運用テストは「使い続ける準備ができているか」を見ます。

受入テストでは、画面の使いやすさ、仕事の流れ、データの正しさ、必要な資料などを確認します。

初心者の方は、まず「受入テストは使う人のための最後の確認」と覚えておくと理解しやすいです。