受け入れテスト（UAT）とは｜重要項目・課題・注意点・実施方法

1. 受け入れテスト（UAT）とは？

2. V字モデルでみる受け入れテスト

3. 受け入れテストで重要視すべき項目とは？

4. 受け入れテストの実施方法・6つのテストタイプ

5. 受け入れテストの流れ

6. 受け入れテストの課題と注意点

7. 第三者検証のすすめ

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

受け入れテストとは、外注したシステムの納品時に、実際に利用する環境またはそれに近い環境でシステムを使用し、問題がないかを確認するテストのことです。

基本的にシステムを発注した側がこのテストを行うことになっていますが、受け入れテストを外部に委託するという選択肢もあります。

受け入れテストはUAT（User Acceptance Test）や検収テスト、承認テスト、ユーザー受け入れテストなどさまざまな呼び方をされることがあります。

受け入れテストの目的と重要性

受け入れテストは一般的に最後に行われるテスト工程であり、システムが求めた要件を満たしているか、使用時に問題はないか、実際の利用環境で快適に稼働するかなどを確認する重要な工程です。納品されたシステムが成果物として認められるかを見極めることが目的であり、受け入れテストを疎かにすると、実際に利用開始した際に思わぬ不具合が起こる可能性があります。

受け入れテストがどれだけ重要なものなのか、おわかりいただける実例があります。

厚生労働省の接触確認アプリ「COCOA」の不具合が4ヶ月も放置されていた問題が大きく報じられたのは記憶に新しいところですが、このアプリの開発では受け入れテストが全く行われていなかったことが報じられています。

厚労省は開発側の機能テストなどの結果をレビューするだけで動作確認ができたと判断し、実機でのテストや実際の利用環境での動作確認は全くしていませんでした。

システムが稼働するかを実際に確認する受け入れテストは、システム開発にとって必要不可欠な工程なのです。

開発における上流工程に対応するテスト工程をV字に見えるよう向かい合わせに並べた図をV字モデルと言います。

このモデルを見ると、上流工程における要件定義に対するテストが受け入れテストであることがわかりますね。

上記はウォーターフォール型の開発におけるV字モデルですが、この場合はテスト工程が大きく分けて下記の4種類あるのがわかります。

・単体テスト（コンポーネントテスト）

・結合テスト

・総合テスト（システムテスト）

・受け入れテスト

これらのテストはそれぞれ目的や重視する項目が異なります。

すでに解説した受け入れテスト以外のテスト工程について確認していきましょう。

単体テスト（コンポーネントテスト）

単体テストとはコンポーネントテストやユニットテストとも呼ばれるテスト工程であり、コンポーネントとは部品や構成要素を指す言葉で、ユニットとは構成単位を表す言葉です。機能ごとに独立しているプログラムをそれぞれ単体でテストします、

単体テストの目的は設計通りにそれぞれのプログラムが動くのか、不具合やバグはないかを確認することにあります。

製造業でイメージすると、部品一つ一つの品質を確認する工程であると言えるでしょう。部品に問題があっては、その後の組み立てに影響が出るため、これも重要なテストです。

結合テスト

単体テストの完了したプログラムを結合し、機能するかを確認するテスト工程です。連携させた時の動作検証が目的です。例えば、パスワード入力機能と、認証機能を連携させ、パスワードを入れたら認証されるかどうかを検証する、といったイメージです。

単体では問題なくても、連携させた際に問題が出ることは少なくありません。開発したプログラム単体同士だけでなく、外部システムとの連携をテストすることもあります。この場合は前者を内部結合テスト、後者を外部結合テストと言うこともあります。

総合テスト（システムテスト）

総合テストとはシステムテストとも言い、すべてのプログラムを組み上げ、完成品として出来上がったシステムが要件の通りに稼働するかをテストする工程です。

開発側が行う最後のテスト工程であり、受け入れテストと内容はほぼ同じです。だからと言ってどちらかを省いてはいけません。必ず、開発側の目線と発注側の目線、両方でテストを行う必要があります。

受け入れテストと他のテストとの違いがわかったところで、この項では受け入れテストにおいて考慮すべき項目、観点について解説します。

受け入れテストにおいてはもちろんすべての機能を実際の環境でテストしたいところですが、リリース直前となるとスケジュールも余裕がなく、少しでもテストする機能を絞る必要があることも。その際に優先的にテストしたいのは「重要な機能」「仕様変更した機能」の２つです。また、実際の環境、実際のデータでテストすることがもっとも重要です。

重要な機能を優先的にテストする

チェック項目を絞る際には、まずは重要な機能から優先的にテストしていくこととなるでしょう。となると、受け入れテストを効率的に行うには、どの機能がもっとも重要なのかを把握しておく必要があります。

仕様変更した機能を優先的にテストする

仕様変更にはトラブルがつきものです。仕様変更があった場合には、仕様変更した機能とそれにかかわる機能を優先的に確認します。仕様変更にそれぞれの機能が対応しているのか、仕様変更はリクエスト通りに行われているのか、仕様変更前のバージョンと間違えていないかなど、しっかりとチェックすることが重要です。

実際の環境、実際のデータでテストする

開発環境と実際の環境は必ずしも同じにできるとは限りません。テストに使うデータも異なります。そのため、実際の環境でテストを行うことが重要です。

先に挙げたCOCOAのトラブルは、これが疎かになったことで大きな問題を引き起こしたと言えるでしょう。

受け入れテストではさまざまなテストが行われます。ここでは一般的な「機能テスト」「疎通テスト」「性能テスト」「回帰テスト」「セキュリティテスト」「ユーザビリティテスト」の６種類のテストタイプについてそれぞれ解説します。

機能テスト

機能が仕様通りに稼働するかどうかを確認するテストです。実際の環境で、実際のデータを使ってテストを行います。例外処理やエラーが出た際の挙動に注目してテストを行うため、前もってエラーが起きる条件を用意して、それに合致したデータを用意しておくと良いでしょう。

疎通テスト

システム間の連携、リクエストとレスポンスがうまく行くかを確認するテストです。データのやり取りがスムーズに行くか、所要時間はどれくらいか、などを検証します。

とは言えこのテストは、受け入れテスト時にはすでに完了されていることがほとんどです。

性能テスト

実際にユーザーが利用する際に問題がないか、実際の利用に耐えられるかを確認するテストです。こちらも基本的にはシステムテストにおいてすでに検証されているため優先度としては低いテスト工程となりますが、受け入れテストで行う際には同時アクセスに耐えられるかどうかを確認すると良いでしょう。

回帰テスト

リグレッションテスト、退行テストとも呼ばれる回帰テストは、システム変更時に変更した箇所とは異なる部分に影響が出ないかを確認するテストであり、受け入れテストでは基本的には実施する必要はありません。

セキュリティテスト

通常の使い方以外に、悪意のある者がシステムを攻撃した際の検証も必要です。システム攻撃された際に問題はないのか、攻撃しにくい対策はなされているかどうかを確認します。セキュリティテストに関しては、本番で使うデータから切り離された環境で行う必要があります。

ユーザビリティテスト

業務に使うシステムであれば、実際に業務を行ったり、ユーザーが利用する際のシナリオを用意しておき、それに沿ってユーザーの操作感などを確認するのがユーザビリティテストです。

受け入れテストはどのような流れで進むのでしょうか。この項では受け入れテストの流れについて簡潔に説明します。

受け入れテストは「計画」「構築・準備」「実施」の3ステップで進みます。ではそれぞれのステップについて見ていきましょう。

計画

受け入れテストの目的や実施する方法、スケジュールなど全体の計画を立てていく工程です。まずは開発側がテスト計画書を作成し、発注側の承認を得てから、テストシナリオなどを定義したテスト仕様書を作成します。

構築・準備

計画書と仕様書をもとに、テスト環境を用意し、テスト参加者や使用する端末、アカウント制限や実施場所などについても事前確認を行います。

テスト参加者は実際にシステムを利用した業務を行っているメンバーを選出します。受け入れテストは実際に利用した際の不具合などを確認するテストなので、そもそも業務内容やシステムの使い方がわからないメンバーではテストの意味がありません。

実施

いよいよ受け入れテストの実施です。一般的に、管理表などを用意してテスト状況を管理します。検証結果は共有した際にわかりやすいように一覧にしておくと良いでしょう。

トラブルが発生した場合は開発側の対応が必要となり、その場合は再テストが必要となります。再テストが滞りなく完了すれば納品です。

受け入れテストの実施方法や流れについて理解できたところで、受け入れテストの課題と注意点についてもおさえておきましょう。

プロジェクト遅延の影響

受け入れテストは非常に重要性の高いテストなのですが、最終フェーズで行われるため、プロジェクトが遅延した影響で受け入れテストの期間がどんどん削られてしまう、ということは残念ながら少なくありません。

とは言え、時間がないからと適当に済ませてしまって、納品後に不具合が見つかって大変なことになる、というケースも。

受け入れテストの重要性を改めて認識し、しっかりと準備と計画を行うようにしましょう。

合否基準の判定

何をもって合格とするのか、合否基準が明確に定まっていない状態では受け入れテストの意味がありません。

受け入れテストの合格基準は下記の流れで決定します。

・ユーザーの要望を「要求」としてテキストに落とし込み、具体的な形にする。

・「要求」をもとにシステムの目的や達成したい目標、方法などについて発注側と開発側がお互いに認識できる「要件」を明文化します。

・「要件」をもとに受け入れテストの合格基準を作成します。

合格基準は複数の基準を設けて、総合的に判断することが理想的とされています。その点にも注意して合格基準を設定すると良いでしょう。

網羅基準の設定

受け入れテストにおいては、本来すべての機能をテストすべきですが、スケジュールの問題などでそれが難しく、必要なテストが不足した結果、不具合やトラブルを招くケースが増えています。

前述したようにチェックする機能の優先順位を決め、リスクが高いもの、優先順位の高いものについては全てのフローを網羅する、網羅基準を設定することが必要でしょう。

テスト設計（テストケース作成）

テストケースを作成するテスト設計も受け入れテストにとっては注意しておきたい重要なポイントです。まずは開発資料一式からテストにおいて確認しなければいけない項目を抽出して整理する「テスト分析」を行い、その項目に対してどのようなテストを行うか、簡易なテストケースを作成します。このひと手間を挟むことで、実際のテストケースの意図がはっきりするというメリットがあります。

いきなりテストケースを作ろうとすると、意図がぼやけてしまうこともあるため、まずはテストの意図をはっきりさせることが重要です。

ここまで解説してきたように、受け入れテストは開発において非常に重要であるにもかかわらず、軽視される傾向にあるのは非常に残念なことです。

受け入れテストを蔑ろにすると大きなトラブルを招くことがあるため、必ず丁寧に行いたいところではあるのですが、自社で受け入れテストを行う際には、発注側が慣れていないため、丁寧に行ったつもりでもできていなかった、というケースもあるかもしれません。

自社で受け入れテストが難しい場合には、第三者に検証してもらう、つまり受け入れテストを外注するという選択肢も視野に入れると良いでしょう。

無視できない不具合の修正コスト

仕様書の不備に起因するバグのテスト工程以降における修正コストは、上流工程で修正を行うコストと比べると何と20倍～200倍にも及ぶ、というデータがあります。不具合は早期に発見することが前提ですね。

受け入れテストで不具合を発見できず、後日発見した際の修正コストも大きなものとなる可能性が高いです。受け入れテストは発注側のチェック工程ですから、ここでOKを出したということは発注側がこれで良い、と判断したということ。

その後に修正、となった場合のコストや、トラブルにおける損失を考えると受け入れテストを軽視してはいけないことがわかりますね。

第三者検証

自社で受け入れテストを行う環境がない場合や、受け入れテストに慣れておらず自信がないという時には受け入れテストの外注を検討しましょう。

ただし、国内ではIT人材の不足が深刻で、テストエンジニアの確保も非常に難しくなっているのが現状です。一方、海外ではテストエンジニアも増加傾向にあり、比較的簡単に人材を確保できます。

国内で急な増員はなかなか難しくても、海外ならリソースの面でもコストの面でもテストエンジニアの増員など、スムーズに対応できることが多いようです。

受け入れテスト以外でも、テスト工程をオフショアへアウトソースする、というようにオフショアを開発するのも良いでしょう。

すでにオフショア開発を委託している場合には、テストも含めて一括で依頼することは難しくありませんが、一括で発注している場合にはすべてお任せとなってしまい、ブラックボックス化しないように気をつけましょう。

可能なら、テスト工程は開発とは別のオフショア開発会社にお願いするなどすれば、より透明性の高く、意義ある開発となるでしょう。

受け入れテストはユーザー目線でシステムの不具合がないかを確かめる重要なテストです。システムテストと内容がほぼ同じということで軽視すると、COCOAの件のように重大なトラブルを招きかねません。

受け入れテストは外注することも可能なので、自社でテストが難しい場合は外注するのも一つの選択肢です。

とは言え、現状国内のIT人材は慢性的な人材不足であり、人件費も高騰しているため、外注をためらう企業も少なくありません。コストや人材不足でお悩みなら、オフショアへのアウトソースを検討してみてはいかがでしょうか。

受け入れテストを含む開発工程においてオフショア開発をご検討の際は、ぜひオフショア開発.comの専任コンシェルジュへの無料相談サービスをご利用ください。お悩みやご要望に最適な企業をご紹介するだけでなく、DXにおけるトレンドなど最新の情報もご提供いたします。