受け入れテスト（UAT）とは？実施方法や重要性をわかりやすく解説

ソフトウェア開発においてソフトウェアテストは、工程ごとにコンポーネントテスト、結合テスト、システムテスト、受け入れテストの4つの段階（レベル）に分けることができます。 そのなかの受け入れテストは、各種テストの最終段階にあたり、重要なテストのひとつです。受け入れテストの役割をきちんと理解し、どのようなテストで何をチェックすべきなのかを明確にしておく必要があるでしょう。

本記事では、受け入れテストの概要と各種テストとの違い、具体的な実施方法について解説します。

受け入れテストとは、完成したソフトウェアが業務要件を満たしているかを検証するために、実際の利用環境もしくはそれに近い環境で問題なく動作するかを確認するテストです。UAT（User Acceptance Test）や承認テスト、検収テストと呼ばれることがあります。外部のベンダーにシステム開発を発注する場合には納品物の検収になりますし、内製であってもシステムが予定通り完成したかを確認する最終のテスト工程となります。

受け入れテストの詳細な計画は実施に間に合えばいいとしても、全体的な計画はプロジェクトの初期工程で行うのが一般的です。システムの完成から稼働までのスケジュールを立てる必要があるので、概要は早期に決める必要がありますが、さらにテスト内容まで初期工程で計画することで、ソフトウェアの利用イメージや業務的な優先度を依頼者側と開発者側の両者で共通認識をもちやすくなります。結果的に、開発者側でコンポーネントテスト（単体テスト）や結合テストなどほかのテストレベルをより要求に沿った方向に計画しやすくなるというメリットもあります。

受け入れテストは、実際の運用環境を念頭に置いたうえで依頼者側が計画し、テストを計画・実行することが理想的です。しかし、依頼者側で受け入れテストに対するリソースが不足している場合や、テスト内容を検討するスキルが不足している場合などは、第三者のパートナー会社の支援を受けて受け入れテストを実施するケースもあります。

受け入れテストについては、こちらの資料がわかりやすくまとまっていますのでぜひご覧ください。
＞＞【初心者向け】受け入れテストで失敗しない！~テストのプロが教えるテスト計画の3つのコツ~のダウンロードページへ

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

▼あわせて読みたい▼
＞＞ソフトウェア開発とは？種類や手法、開発の流れやコツについてわかりやすく解説のページへ
＞＞コンポーネント（単体、ユニット）テストとは？手法などを例で紹介のページへ
＞＞結合テストとは？目的や観点・種類・単体テストとの違いを解説のページへ
＞＞システムテスト（総合テスト）とは？その目的・観点・種類、実務で使える手順について解説のページへ

V字モデルとは、システムの開発工程をV字に並べ、対応するテストレベルを記載して図式化したものです。設計のレベルとテストのレベルを同じ高さに対応付けることで、それぞれのテストレベルで行うべきテストを明確化し、テストの抜けや漏れを削減できる効果があります。

V字モデルについてはこちらもご覧ください。
＞＞V字モデルとは？開発とテストの流れ、活用するメリット・注意点を解説のページへ

V字モデルにおける受け入れテストは要求分析に対応するテストレベルに位置付けられています。要求分析は、システムの導入によってどのように業務処理が変わってどのように効率化されるかという分析で、受け入れテストは想定した業務処理の効率化が達成できたかを判断するテストです。

システム稼働前の最後のテストであり、ここをクリアして初めて業務に利用できる品質を担保できたとなります。受け入れテストを納品物の確認だけにとどめて業務への適合性の確認を蔑ろにしてしまうと、そのソフトウェアを利用すると却って業務が非効率になる可能性があるため、業務観点のテストを軽視したり実施したりしないという選択肢はないといっても過言ではありません。

改めて受け入れテスト以外のテストレベルでテストする領域を確認してみましょう。受け入れテスト以外のテストレベルには、以下のものがあります。

・コンポーネントテスト（単体テスト）
・結合テスト（統合テスト）
・システムテスト（総合テスト）

それぞれのテストレベルでは、確認する項目や目的が異なります。受け入れテストと何が異なるのか、詳しく見ていきましょう。

コンポーネントテストは、作成したプログラムや画面を、できるだけ小さな範囲でテストする段階です。プロジェクトによっては、単体テストやユニットテストといわれているケースもあります。プログラムであれば関数やメソッドあるいはAPIの単位で動作のテストを行い、画面であればそれだけを表示して見た目や動作を確認します。具体的には次のような内容です。

関数A：1000円の商品の消費税を計算すると100円が返ってくる
画面XB：パスワード入力域に文字を入力すると「●」で表示される

受け入れテストが業務的な視点で確認するのに対して、コンポーネントテストは作成された内容が正しいかどうかを個別に確認します。コンポーネントテストの目的はあくまでも作成されたプログラム単体が詳細設計書通りに動作するかどうかであり、業務的な意味合いに関してはあまり重視していません。どちらかというと、作成されたプログラムや画面が作成者の意図通りになっているかどうかを確認する意味合いが強いのがコンポーネントテストにあたります。

業務的な要件は要件定義・基本設計までで細分化され、詳細設計に直接影響することはないので、受け入れテストでコンポーネントテストレベルのテストを実行することはほぼありません。しかし、コンポーネントテストには自動化されている部分が多く、後の保守を想定して自動化されたテストが再実行できる環境を確認することは受け入れテストのなかで行う必要があるでしょう。また、コンポーネントテストが十分に実施されたエビデンスとして、コンポーネントテストのカバレッジを確認するケースもあるでしょう。

コンポーネントテストの詳細は、以下の記事を参考にしてください。
関連記事：コンポーネント（単体、ユニット）テストとは？手法などを例で紹介

結合テストとは、コンポーネントテストで基本動作が確認された部品を組み上げながら、部品間の連携が想定通りに動作するかどうか確認します。統合テストと呼ぶケースもあります。また、結合テストで基本設計書に記載された機能を網羅的に確認することも一般的です。コンポーネントテストでは単体での機能に不具合がないかを確認していましたが、それらが組み合わさった際に不具合が発生しないかどうかを確認するテストだと思っておきましょう。

ユーザー認証の一部を例にあげてみると、次のようになります。

・機能B：ログインが未の状態である場合に、ログイン画面を表示する
・画面X：入力したユーザーIDとパスワードが、認証処理に伝わる
・機能C：ユーザーIDとパスワードが一致した場合、メニュー画面に遷移する

このように「機能Bから画面Xへの遷移」「画面Xの入力内容が機能Cに連携」といった機能と画面のつながりに対して、画面遷移やデータの伝達が仕様通りに動作するかテストを行います。

コンポーネントテストと同様、結合テストも業務的な視点を重視しないテストです。結合テストは基本設計書に沿って、異なる機能同士が連携した際に不具合が発生しないかを確認します。

基本設計書には業務を構成する機能が表現されていることが多く、受け入れテストで結合テストレベルのテストを実施することはよくあります。ただし、受け入れテストでは基本設計書ベースではなく、業務的な意味で動作を確認することになります。もちろんすべての結合テストを再実行するのは時間がかかりすぎるので、業務に重要なところをピックアップして実施することになります。

結合テストの詳細を知りたい方は、次の記事も参考にしてください。
関連記事：結合テストとは？目的や観点・種類・単体テストとの違いを解説

システムテスト（総合テスト）では、完成品として仕上がったソフトウェアがインフラも含めたシステムとして要件定義通りに動作するかを確認するテストです。あらかじめ実務で想定されるようなシナリオを設計して、実際に本番環境、もしくはそれに近い環境で動作させながらテストを行います。

例えば、ユーザーがパスワードを忘れてしまったと想定しテストを行ったり、アクセスが集中することを想定して負荷をかけたりするなどのテストを実施します。

要件定義には業務的な要件も強く反映されるため、システムテストと受け入れテストとでほぼ同じ内容のテストを実施することもありますが、システムテストの場合は開発者視点でシステムとしての不備がないかに着目します。受け入れテストでは依頼者の観点でより業務的な確認を行うことになり、両者の目的が異なることに注意してください。システムの内部的な確認はシステムテストが最後となるため、開発者視点で不具合を見つける最後のチャンスでもあります。

システムテストの詳細を知りたい方は、次の記事も参考にしてください。
関連記事：システムテスト（総合テスト）とは？その目的・観点・種類、実務で使える手順について解説

受け入れテストはテスト工程において最後に実施する工程であり、必要不可欠なテストです。すでに開発とテストが最終段階に入っているシステムを、開発を依頼した側が実際に使用する環境やそれに近い環境で業務や運用の観点で検証を行います。

「依頼側が求めている要件は満たしているか」や、実際に使用するユーザーが「快適に利用できるか」「使用するうえで不都合はないか」など実際の利用を見据えた検証結果を得なければ、本当の意味でシステムの完成とはいえません。仕様書に沿ったシステム開発であったとしても、仕様書に絶対に誤りがないとはいえません。実際の利用環境においてそのシステムが機能しなかったり使いにくかったりすれば、システムを利用した業務が進行しない可能性などもあります。その結果、せっかく作ったシステムが利用されなくなってしまう可能性もあるでしょう。

そのような事態を防ぐため受け入れテストを行い、システムの最終的な完成を確認する必要があるのです。開発者視点だけではなく、依頼者視点でのテストも、使いつづけてもらうソフトウェアを開発するためには必要不可欠なのです。

テストタイプとは、テストで確認したい目的別に分類したものです。一般的によく用いられる代表的なテストタイプは以下の6種になります。

受け入れテストでは、実際に使用するユーザーが中心となってシステムが存在する目的を達成できているかを確認することが重要です。そのため、システムテスト以前にはあまり考慮されていない実際のユーザーや運用者、実際の環境やデータに関わるテストを中心に実施します。前のテストレベルでほとんど完了していると考えられるテストもありますが、業務的な観点、利用者や運用者の視点で必要なテストがあれば実施しましょう。

これらをふまえて、それぞれのテストタイプを確認してみましょう。

機能適合性テストは、システムの機能が提供されている、計算やデータ格納が正しい、業務の遂行に役に立つという観点で実施するテストです。要件定義、基本設計、詳細設計として落とし込んでいった仕様が、システムとして正しく提供されているかということを、コンポーネントテスト、結合テスト、システムテストの工程で確認していきます。

受け入れテストでは、特に業務の観点での確認が必要です。要件定義で提示したシステムの機能が実際の業務に十分だったか、業務的な観点で計算やデータ格納が正しいか、システムの利用が本当に業務の効率化に役立っているか、こういったことを確認します。

性能効率性テストは、ソフトウェアの実行時間ないし時間当たりの処理数、CPU・メモリなどのリソースの使用量、利用者数やデータの量を確認するテストです。一般的には単体での実行時間をコンポーネントテストで確認したり、複合した機能の実行時間を結合テストで確認したりしたうえで、システムテストの段階で負荷テストおよびキャパシティテストを行います。

システムテストのときに、実運用に近しいインフラ上で、実業務の特性とデータ量を反映したテストデータを用いてテストが行われていれば、改めて受け入れテストで性能効率性テストをする必要性は薄いでしょう。もし実際の運用環境とシステムテストで利用した環境が違うようであれば、改めて性能効率性テストを計画しましょう。単に目標の数値をクリアすることを確認するだけでなく、それ以上にアクセス数が増えたら、データが増えたら、何が起きるかということも確認しておくことをおすすめします。

互換性テストは同時に動いているほかシステムとの連携に問題がないか、同じ実行環境上で同時に動いているほかのソフトウェアとの競合がないかを確認するテストです。この場合はスマホなどの端末もほかシステムとして認識する必要があります。特にWebで公開されるシステムでは、多種多様な端末から同じく利用できるかというテストが重要になります。

システムテストのときと実運用で、システムの運用環境が変わったり、ネットワーク環境が変わったりという状況があるのならば、受け入れテストの間に確認しておく必要があります。接続する外部システムもシステムテストまではダミーを使っていることが多いので、実際の外部システムで確認する必要があるでしょう。

ユーザビリティテストは、想定した利用者、想定したシステム利用の状況、想定したシステム利用の目的において、システムが目的に対して有効で、システムの利用で効率性が高くなり、利用者も満足できることを確認するテストです。利用者が迷わず業務に利用できるか、利用者の誤りが防げるか、利用者が気持ちよく操作できているかというところが確認ポイントになります。

システムテストで、業務に沿ったシナリオを作成し、想定の利用者に近いテストユーザーに操作させてユーザビリティを確認することはありますが、実業務の状況まで再現させるのは困難なところがあります。そこで受け入れテストの段階で、実際に業務を行っている環境で、ほかシステムの利用やシステム外の人間の作業なども含めて、利用者が問題なくシステムを使えるかを確認します。またシステムの開発者と実際の利用者のITリテラシーに差があると、利用者が入力ミスをしたときにエラーメッセージが理解できるのか、どこまで自己解決できるかという観点も重要になります。

システムは永久に動いているものではありません。さまざまな要因で、意図的に止めたり、また偶発的に止まったりします。信頼性テストは、意図的に止める時間の間に作業が終わることを確認し、偶発的に止まる可能性が低いことを保証し、止まってしまった後の回復手順を検証するテストです。

実運用に携わる人は、開発時に関与する人と異なることが多いです。そのため、受け入れテストでは実際の運用者が間違いなく作業ができるかという観点が重要になります。現在の業務はシステムが支えていることが多く、システムが止まると業務も止まってしまうということも珍しくはありません。運用の作業は予定の停止時間で終わることに加え、万が一システムが止まってしまったときにどのくらい速やかに復旧できるかということが重要になります。注意していただきたいのはシステム停止を引き起こした原因、例えば壊れたデータを取り除かないと、システムを再起動しただけでは復旧にならないということです。問題の原因を絞り込む手順なども受け入れテストで確認するようにしましょう。

セキュリティは、システムが対策していれば終わりというわけではなく、利用者の行動や組織的な取り組みも関わってきます。特に最近は、セキュリティが向上しているシステムに正面から攻撃するのではなく、利用者をメールなどで誘導して利用者のPCを踏み台にしようという攻撃が増えています。したがって、セキュリティテストではシステムを直接攻撃するテストのほかに、新しいセキュリティリスクの対策ができているか、利用者の教育が行き届いているか、といった観点の考慮が必要となります。

受け入れテストでは、さまざまなセキュリティリスクを確認したうえで、システム自体で防げる対策はできているのか、利用者や運用担当者からの情報漏洩防止が教育などの人的対策に組み込まれているか、万が一情報漏洩が発生したときの検出や追跡が可能か、といった観点でセキュリティ対策を確認しましょう。

＞＞セキュリティサービスについてはこちらからご確認ください

受け入れテストを実施する際は、次の3つのポイントを意識するようにしてください。

・優先順位をつけてテストを実施する
・実際のデータでテストを実施する
・連動するシステムの挙動も確認する

主にリスク管理を意識した場合のポイントですが、いずれも受け入れテストを実施するのに必要な観点です。それぞれ詳しく見てみましょう。

システムを使う業務に優先度を付け、重要度の高い業務からテストを実施するようにしましょう。業務の効率化のために作ったシステムを、いつまでもテストのために寝かせておくこともできないので、テスト期間は限られます。すべての機能をチェックする余裕がないケースも珍しくありません。もちろん、すべてテストできれば理想的ですが現実的ではないため、特に重要度の高い業務を最優先にテストをするようにしましょう。

同時に、通常の業務だけをテストすればいいわけではありません。予定が変わったとか予定通りに進まなかったなどの異常事態から業務的にリカバリーできるかどうかを確認することも重要です。受け入れテストにおいては、通常時を想定したテストに加え、特別なリカバリーが必要となる状況を想定したテストを実施するようにしてください。

実際のデータでテストを実施すると、開発中に気が付かなかった問題を検出できる可能性があります。一般的にソフトウェア開発中に使用されるデータは疑似データであり、本番のデータとは異なりますし、データ量も少ないことが多いです。テストが不十分なまま稼働して、実はデータの特性が違ったりデータ量が多かったりして性能が追い付かなかったということもよくあります。

このような状況を回避するためにも、受け入れテストで実データを用いたテストを実施しましょう。本番環境に移行した際のリスク軽減を実現するためにも、実際のデータを用いたテストを行ってください。また、ネットワーク環境も、実際の運用環境に合わせて確認しましょう。

連携するシステムがどのように動作するのか、挙動も併せて確認する必要があります。ソフトウェア開発においてむずかしいといわれるものに、仕様変更があります。開発途中で仕様変更を実施すると、開発者側の意識が仕様変更に向いてしまい、そのほかの部分での対策の抜けや漏れが発生してしまう可能性があるのです。あるいは、連携相手が仕様変更に対する影響に気が付かないまま、開発を進めてしまう可能性もあります。

受け入れテストを実施する際には、対象システム開発中に連携する各外部システムに仕様変更がなかったかを確認しましょう。仕様変更があるならばそれが反映されているか、あるいは仕様変更がないにしても連携するシステムの挙動が想定通りであるかを確認するようにしましょう。

受け入れテストは、4つのテストレベルのなかでも重要度が高いといえるテストです。発注者のニーズを満たしているか、業務観点の不具合はないかを利用者目線で確認することで、開発者視点では見えなかったものが見えてくることがあります業務の現場で利用したときに業務の進行に差し支えないか、入力エラーに対して表示されるメッセージが利用者に理解できるものであるか、業務上の課題が発生した際に、リカバリー運用ができるかなど重要な確認ポイントが多くあります。リリース後のシステムの運用をスムーズにするためにも、必ず実施してください。

受け入れテストをはじめとするテストでお悩みの方は、ぜひSHIFTまでお問い合わせください。SHIFTはソフトウェアテストに強みをもっており、数多くのソフトウェアテストを実施しています。多くの不具合を発見してきたノウハウを生かし、ソフトウェアの品質を第三者として担保できるのです。ソフトウェアテストの実施に不安がある、受け入れテストのノウハウが少なく助けてほしいという方は、ぜひSHIFTまでご相談ください。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

質の高いソフトウェアテストを効率よく行うためには、多くの知識や経験が必要です。社内に経験豊富なIT人材が不足していると、質の高いテストを実施するのがむずかしく、かといって一からIT人材を集めるためには膨大な時間とコストがかかってしまいます。

そのような悩みは、SHIFTのソフトウェアテスト・第三者検証のサービスを利用いただくことで解決できます。

＼おすすめの資料／　※すべて無料でダウンロードいただけます。
・3分で知るSHIFTのテストサービス
・テスト効率が大幅アップ、人手不足解消の切り札に ＜理由＆メリット＞
・ソフトウェアテストを外注すべき5つの理由とは！？
・サービス導入事例集

これまで導入いただいた企業様は3,000社以上。その豊富な専門知識と経験を活かして、高品質のソフトウェアテストを効率よく行い、開発のサポートをいたします。

ぜひSHIFTのソフトウェアテスト・第三者検証をご利用ください。

ご相談はこちらから。
＞＞お問い合わせ
＞＞料金について

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座