受け入れテスト（UAT）とは？ 6つの実施方法やポイントを紹介

受け入れテスト（UAT）とは何か

まず、受け入れテスト（UAT）の概要と、「V字モデル」における位置づけ、結合テストやシステムテストといった各種テストと受け入れテストの違いについて紹介します。

受け入れテストとは

受け入れテストとは、完成したシステムやソフトウェアが要件を満たしているかを検証するためのテストです。実際の運用環境もしくはそれに近い環境で、ユーザーのニーズを満たし、実務上の不具合や使いにくさがないかを確認します。

受け入れテストは「承認テスト」「検収テスト」とも呼ばれ、一般的にソフトウェアテスト工程の最後に実施されます。開発側ではなくシステムの発注側が行うものですが、専門性を持った人材やリソースが不足している場合には、外部に委託するケースもあります。

受け入れテストの目的

受け入れテストの目的は、納品されたシステムがユーザーの要件やニーズを満たし、実際の利用環境で成果物として認められるかを見極めることです。受け入れテストを軽視してしまうと、実務を行う段階になって初めて予想外の不具合に悩まされる、といった事態が起こりかねません。

受け入れテストの特徴

受け入れテストはテスト工程の最後に行うものですが、テストの全体的な計画はプロジェクトの初期から行うのが一般的です。計画を立てる際には、まずはテスト範囲や工数、リスクと対策などの概要を定めます。これにより、システムが完成してから実務で運用するまでのスケジュールを明確にすることが可能です。

その際、テスト内容までを初期段階で計画できれば、ソフトウェアの実際の利用イメージが湧きやすくなり、発注側と開発側とで共通認識を持ちやすくなります。結果として、コンポーネントテストや結合テストなど、受け入れテストの前に実施する各種テストの精度や効率を向上させることにもつながります。

V字モデルにおける受け入れテストとは何か

V字モデルとは、システムの開発工程とテスト工程をV字に並べ、それぞれの対応関係を図式化したものです。システム開発の流れとともに各開発工程で行うべきテストを明確化することで、テスト範囲の重複や抜け漏れを防ぎ、後工程での手戻りのリスクを軽減しやすくなります。

V字モデルにおける受け入れテストは、「要求分析」に対応するテストレベルです。要求分析は、ユーザーが実際の業務環境でシステムを活用するにあたって、何を実現したいのか、何ができなければ困るのかといったニーズを明確にする工程です。受け入れテストでは、そのニーズが実際に満たされているのかを判断します。

V字モデルにも表現されているように、受け入れテストはシステム稼働前の最後のテストであり、品質を担保するために欠かせないプロセスとして位置づけられています。業務の効率化を見込んだシステムの導入によって、かえって業務効率が下がってしまうような事態を防ぐためにも、受け入れテストの実施は確実に行う必要があります。

受け入れテストとコンポーネントテストは何が違うのか

コンポーネントとは構成要素や部品を意味する言葉で、コンポーネントテストは機能ごとに独立したプログラムを単体でテストするテスト工程です。単体テスト、ユニットテストとも呼ばれます。例えば、ECサイトでのログイン画面はさまざまな要素で成り立っていますが、「ログイン画面を表示する」「入力されたIDとパスワードをデータベースで照合する」など、プログラムが機能単位で設計どおりの動作をするかを確認します。

受け入れテストでは、そうした個々のプログラムの動作ではなく、システム全体が実業務での活用に適しているのかをユーザー視点で総合的に確認します。

なお、要求分析の内容は、要件定義や基本設計までで十分に細分化されるため、V字モデルでコンポーネントテストに対応する「詳細設計」にまで直接影響することはありません。そのため、受け入れテストのなかでコンポーネントテストのようなテストを実行することは少ないといえます。ただ、システム変更時のリグレッションテストの実施など、のちの保守を見越して、自動化されたコンポーネントテストを適切に再実行できる環境であるかの確認は必要です。

受け入れテストと結合テストは何が違うのか

結合テストとは、コンポーネントテストで問題なく動作することが確認されたプログラムやモジュールを組み合わせた際に、意図したとおりに連携して動作するかどうかを検証するテストです。インテグレーションテストとも呼ばれます。

例えば、ECサイトにおけるユーザー認証の場合、以下のような機能単位が考えられます。

• 機能A：ログアウト状態ならログインフォームを表示する
• 機能B：入力されたIDとパスワードをデータベースで照合する
• 機能C：ユーザー認証が成功した場合に、個別のアカウント管理画面に遷移する

結合テストでは、これらの機能が仕様どおりに連携することで「ログアウト状態からアカウント管理画面に遷移するまで」の一連の動作が行えるようになっているかを確認します。一方、受け入れテストの場合は、こうした機能同士の連携確認を経て、システム全体が正常に動作するかどうかを検証します。コンポーネントテストとの違いと同様に、両者はテストを実施する範囲と目的において異なるといえます。

なお、V字モデルで結合テストと対応する「基本設計」の段階では業務に必要な機能が多く含まれるため、受け入れテストでも結合テストと同レベルのテストを行うことは珍しくありません。ただ、受け入れテストの場合はあくまでも業務要件を満たしているかどうかの観点から、特に重要な動作について確認します。

受け入れテストとシステムテストは何が違うのか

システムテストは総合テストとも呼ばれ、すべての機能が整いシステムとして仕上がった段階で、要件定義通りに動作するかを確認するテストです。実際の使用状況を想定した環境で、実務で想定されるシナリオに基づいて全体的な確認を行います。

例えば、サーバーダウンなどの疑似的な障害を発生させて復旧手順を確認したり、アクセスが集中して過負荷になった状態でもシステムが正常に動作するかを確認したりします。

V字モデルでシステムテストに対応する「要件定義」には業務要件も色濃く反映されるため、受け入れテストとシステムテストとで実施するテスト内容は非常に似通ってくる場合があります。ただ、システムテストでは開発側の視点からシステムとしての不備に着目するのに対し、受け入れテストでは、発注側の立場で実務の現場に即した確認を行う点で異なります。

なお、システム内部の構造や動作に関する確認は、システムテストが最後の機会です。発注側による納品前の最終チェックが受け入れテストであり、その前段階で問題がない品質に仕上がっているかどうかを開発側が確かめるのがシステムテストです。

受け入れテストが大切な理由

前述したとおり、受け入れテストはテスト工程の最後に実施するテストであり、ユーザーニーズを満たしたシステムを開発するために必要不可欠なものです。

ユーザーから本当に求められるシステムは、単純に仕様書に沿うだけで完成するわけではありません。仮にスムーズに開発が進められたとしても、そもそもの仕様書に誤りがないとは言い切れず、実際の利用環境で必要な機能に不具合があったり、不具合はなくても実用性に欠けていたりすると、かえって業務に支障を来す恐れがあります。そうなれば、多大な労力とコストをかけて開発したシステムが生かされません。

そういった事態を防ぐためにも、受け入れテストを確実に行い、実際にシステムを利用するユーザーが業務の現場で快適に利用できるかを確認し、必要に応じて修正を加える必要があります。開発側だけでなく発注側の観点も大切にすることで、長く信頼されるシステムの構築に近づけることが可能です。

受け入れテストを成功させるポイント

受け入れテストを成功させるには、まずテスト計画を早期に立て、ソフトウェアの利用イメージを明確にすることが大切です。また、受け入れテストを行うために使用する機材やテストデータなどは、実際の利用環境と同様のものを用意することも重要です。限りなく本番環境に近づけることで、想定にない動作やトラブルを避けることにつながります。

そして何より大切なのが、そもそもの業務要件を満たしているかの確認です。ユーザーニーズを考慮し、システム化の対象となる業務の流れをくんだシステムでなければ、実務では役立ちません。

代表的な6種類の受け入れテスト

受け入れテストでは、確認したい内容ごとにさまざまなテストが行われます。ここでは、よく用いられる代表的なテストタイプである「機能適合性テスト」「性能効率性テスト」「互換性テスト」「ユーザビリティテスト」「信頼性テスト」「セキュリティテスト」の6種類について紹介します。

なお、ここで挙げるテストは受け入れテストの工程に限らず、コンポーネントテストやシステムテストといったほかのテスト工程でも用いられることがあります。

テストタイプ	概要
機能適合性テスト	実際のデータを用いた場合でも、必要な機能が仕様どおりに問題なく提供され、 業務の効率化に役立つかを確認するテスト。
性能効率性テスト	アクセス数やデータ量などにおいて、実際にユーザーが利用する場面を想定した際に 問題なく運用できるかを確認するテスト。
互換性テスト	既存のインフラをはじめ、ほかのシステムと適切に連携できるか、 同じ実行環境で動くほかのソフトウェアと競合しないかを確認するテスト。
ユーザビリティテスト	ユーザーが業務で利用する際に、迷わず適切に操作できるか、 快適な使用感を実現できているかを確認するテスト。
信頼性テスト	システムに異常が発生した際に迅速に復旧できるか、 保守作業は想定どおりに終えられるかなど、 安定的な運用が可能かを確認するテスト。
セキュリティテスト	通常の利用以外に、システムが攻撃された際に問題がないか、 攻撃を未然に防ぐための対策がなされているかを確認するテスト。

受け入れテストでは、より実際の運用を想定した環境下で、システムが目的を果たせるかを確認することが大切です。受け入れテストより前の段階ではあまり考慮されていない業務的な観点を中心に、ユーザーの立場で考えて必要なテストを実施します。

以上の概要を踏まえて、それぞれのテストタイプの詳細な内容を見ていきます。

機能適合性テスト

機能適合性テストは、ユーザーの求める機能がどの程度実現できているかを確かめるためのテストです。詳細設計にまで落とし込まれた仕様がシステムとして正しく提供されていることを、コンポーネントテストからシステムテストまでの各テスト工程で確認していきます。言葉で明確化された要望だけでなく、潜在的なニーズまで的確にくみ取りながら開発されたシステムは、特に機能適合性が高いといえます。

受け入れテストの段階で実施する機能適合性テストでは、業務要件を満たしているかの確認を重点的に行います。システム内で正しい計算やデータ処理が行われているかなど、要件定義で定めた機能が実際の業務環境下で十分なものだったか、システムの利用によって本当に業務の効率化が実現できているのか、といったことを確認します。

性能効率性テスト

性能効率性テストは、機能実行時の性能や資源効率を確認し、問題なく運用できるかを確かめるためのテストです。ユーザーがシステムを操作した際のスムーズな応答を保証するために、応答速度および処理速度と、メモリやCPU・ディスク容量の使用効率を評価します。

コンポーネントテストでは機能単位で、結合テストでは複合的な機能の確認をした上で、システムテストでは高負荷テストやロードテストを行い、性能と耐久力のバランスが取れているかを検証します。

ここまでの段階で、ある程度実際の業務環境に近しい運用環境とデータを用いてテストを行えていれば、受け入れテストの工程で改めて性能効率性テストを実施する必要はないともいえます。そういった意味ではやや優先度が低いですが、同時アクセス数を増やす、データ量を増やすなど、イレギュラーな状況下でどのような挙動を見せるのかを詳しく確認しておくと、システムへの信頼感をさらに高められます。

互換性テスト

互換性テストは、環境依存の不具合を見つけ、さまざまな利用環境で快適にシステムを利用できるようにするためのテストです。ほかのシステムと適切に連携できるか、同じ実行環境で動くほかのソフトウェアと競合しないかを確認します。例えばPCやスマートフォンなどのハードウェアやWebブラウザが異なる場合でも、同じような挙動を実現できる必要があります。

互換性テストの実施には、外部接続機器やバージョンの異なるアプリケーションなどが必要であり、テスト環境の構築に一定の手間がかかりやすいというハードルがあります。ただし、最終的な動作を確実なものとするため、システムテストのときと比べてネットワーク環境やシステムの運用環境に変化がある場合には、改めて受け入れテストの工程で互換性テストを実施するべきだといえます。

ユーザビリティテスト

ユーザビリティテストは、開発しているシステムが提供したい価値と、実際のユーザー体験が一致しているかを確認するためのテストです。あらかじめ想定している利用者や利用状況を用意し、迷わず適切に操作できるか、快適な使用感を実現できているか、システムはユーザーの利用目的を果たせるものかを確かめます。

システムテストの段階では、業務を想定したシナリオを用意してユーザビリティを確認することはあっても、多くの場合で、実際の業務環境を再現するまでには至りません。そこで受け入れテストの段階で、使用環境やシステム利用者、関連するほかのシステムでの作業状況も含めて再現し、問題なくシステムが使えるかを確認します。操作ミスやシステムエラーが発生した場合に、どの程度であればユーザーが自ら解決に向けて動けるのか、といった観点も大切です。

信頼性テスト

信頼性テストは、どれほど想定どおりにシステムが機能を提供し続けられるかを検証するためのテストです。システム障害が起こりにくいか、障害が発生した場合には迅速に復旧できるか、保守作業でシステムを意図的に止めた場合には想定どおりに作業を終えられるかなど、安定的な運用が可能かを確かめます。

システムの納品後は、それまで開発に携わっていない人がシステムの運用を担うと想定されます。そのため受け入れテストでは「実際のシステム運用担当者が問題なく作業できるか」という観点を大切にします。

また、どの業界のどのような業務であれ、現代ではシステムがなければ成立しない場面は多く、そもそもの不具合の少なさや復旧にかかる時間の短さは特に重要といえます。受け入れテストの段階で、システムが停止した場合に素早く原因を絞り込んで解決するための手順を明確にしておくことが必要です。

セキュリティテスト

セキュリティテストは、不正な侵入やなりすましといった悪意のある第三者の攻撃から、システムを守るための対策が適切になされているかを確認するためのテストです。

特に近年では、ランサムウェアによる被害や標的型攻撃メールによる機密情報の窃取など、脅威の種類も多様化しています。そのため、従来のセキュリティ対策だけでなく、多要素認証やAIによる脅威の可視化、ゼロトラストの導入など、幅広い観点でのセキュリティ対策が求められています。

受け入れテストでは、そういったセキュリティリスクを踏まえた上で、システムへの直接的な攻撃を防げる状態か、もし情報漏洩が起きた場合には迅速に検出して追跡できるか、といった観点でセキュリティの脆弱性を確認します。システム利用者のセキュリティ意識を高めるための教育がなされていることも、同様に大切です。

受け入れテストを効果的に実施するコツ

受け入れテストはシステムの稼働直前に行う重要なテストですが、コストを抑えるためには二度手間を防いで効率よく進めなければなりません。重要な機能と仕様変更があった機能を優先し、実際の業務環境とデータを用いてテストを行うことが大切です。

優先順位をつけてテストを実施する

受け入れテストを実施する際には、重要な機能を優先的に扱うことが大切です。受け入れテストはシステムの最終確認として行うため、機能のすべてを念入りにチェックする時間的余裕がない場合が珍しくありません。システムの中でも、不具合の発生を特に避けるべき重要な機能、主たる機能を洗い出し、明確な優先順位をつけてテストを実施する必要があります。

その上で、どのような条件下でテストを行うかを決めていきます。このとき、通常の業務での利用だけを想定するのではなく、定期的に発生するイベント時の対応や、イレギュラーな状況を想定したテストを実施しておくことが望ましいです。

特に重要とされる機能を想定どおりに利用した場合に誤作動を起こさず、仮に誤作動を起こしたとしてもシステムが完全に停止してしまうような致命的な事態に陥るリスクを減らすことが重要です。これらの観点から受け入れテストを行うことが求められます。

実際のデータをテストに利用する

実際の運用環境であるだけでなく、実際に扱うデータを利用してテストを実施することも大切です。システム開発の現場では疑似的な環境で疑似データを用いる場合が多く、最終的に本番環境で稼働させる場合と比べると、データの特性が異なっていたり、データ量に過不足があったりする場合があるためです。

受け入れテストの段階で実データを用いてテストを行っておくと、開発中には気づかなかった問題を検出でき、本番環境に移行した際に処理漏れが発生するリスクを抑えやすくなります。実務でシステムを稼働させた後で、実は性能が追いつかないことが判明したり、誤作動を起こしたりしないよう、可能な限り細部まで本番環境に近づけようとする姿勢が必要です。

関連システムの挙動も合わせて確認する

開発中のシステムと連携する外部システムの「挙動」を確認しておくことも大切です。なぜなら、開発中のシステムに仕様変更が起きた場合、開発側は限られた時間の中で対応しなければならず、外部システムと連携する部分への悪影響を放置してしまっている可能性があるためです。

それと同時に、テスト対象となるシステムの開発中に「連携する外部システムに仕様変更がないか」も注視しておく必要があります。いずれかの箇所に仕様変更があった場合には、まずは該当機能と、その関連機能を優先的にテストすることが望ましいです。仮に仕様変更が一切なかったとしても、連携するシステムの挙動が適切であるかの確認は欠かせません。

受け入れテストの4つの課題

受け入れテストの課題について、代表的なものを4つ紹介します。受け入れテストは重要なテストですが、開発工程の最後に行われるために発生する課題や、テスト対象となる機能が幅広いために生じる課題などが存在しています。

十分なテスト期間の確保

受け入れテストは、その性質上、開発の最終段階で実施されます。そのため、重要度は非常に高いにも関わらず、開発プロジェクトのスケジュール遅延の影響を受けてテスト時間が削られてしまう、といった状況が起こりやすいといえます。必要なテストを省略してしまったり、テスト過程でミスが起きたりすれば、十分な検証とはならず、リスクを放置してしまいかねません。

受け入れテストを行う際には、効率良く実施する体制を整えるだけでなく、テスト期間そのものを十分に確保しておくことが大切です。必要なリソースが不足している場合には、専門家に任せるとスムーズです。

合否の判定

受け入れテストを実施する際には、明確な合否判定の基準をあらかじめ設けておく必要があります。この基準が曖昧だったり、主観的なものだったりすると、結果に信頼性が持てず、正確な検証として成立しません。

合否判定の基準は、ユーザーの要望を具体的に分析して作成した要件定義書の内容に基づいて設定します。このとき、テキストだけでなくデータを用意するなどして複数の基準を設けることができれば、より的確な判断が可能となります。

網羅基準の設定

受け入れテストでは、理想として、できる限り多くの機能を細部にわたって確認するべきです。ただし、前述したようにスケジュールに余裕がない場合が珍しくなく、システムの規模が大きくなればなるほど、幅広くかつ詳細にテストを行うのは現実的ではありません。その結果、必要なテストが行われないことにもつながってしまいます。

実務で運用する段階でトラブルが起こらないようにするためには、まずは優先順位をつけてテストを実施することが重要です。特に優先度が高いものやリスクの高いものについては、例外的な動作やエラーハンドリングも含めて、あらかじめ網羅基準を設定しておくのが効果的です。

テスト設計

具体的なテストケースを作成する「テスト設計」も、受け入れテストを実施する上で注意が必要です。まずは、要件定義書をはじめとする開発資料からテスト観点を洗い出す「テスト分析」を事前に行い、その結果に応じて簡易的なテストケースを作成しておくと良いといえます。

最終的にテストケースに落とし込む前に、テスト分析を行うことで、テストを行う目的や意図が明確になり、テスト精度が高まりやすくなります。ユーザーがシステムをどのように操作するのか具体的なイメージを持ちながら、なるべく細かい動作項目を記載することが大切です。

まとめ

受け入れテスト（UAT）について、その意味や目的、各種テストとの違いや効果的な実施のコツなどを詳しく紹介しました。システム開発には不具合がつきものですが、納品前に実際の運用環境でテストを行うことで、よりユーザーのニーズを満たす、使い勝手の良いシステムに近づけることが可能です。

受け入れテストを軽視してしまうと、実務の段階で致命的な不具合が発生しかねません。多大な工数と費用を浪費する結果に終わらせないためにも、受け入れテストは確実に実施することが大切です。