受け入れテスト(UAT)とは？システムテストとの違いも解説
システム開発において、テストをおこなうことは、製品の品質を保つ上で非常に重要です。
そのため、開発にはいくつかのテスト工程が存在し、「受け入れテスト」もそのひとつです。
UATや検収テストとも呼ばれるこの工程は、システムが実際に稼働する前の、最終段階に当たる、重要なプロセスです。
外注する企業も増える一方、基本的にはシステムを実際に使用する側がおこなうテストですが、十分なコストがかけられない、対象項目を絞るのが難しいなど、多くの課題があります。
このプロセスは、納品したシステムを使って円滑に業務ができるかを左右するため、不足なくおこないたい部分です。
この記事では、受け入れテストとはどのようなものか、実施内容や重要性、関連するプロセスについて、解説します。
合わせて、システムテストとの違いや、受け入れテスト実施時に気をつけたいポイントについても見ていきましょう。
受け入れテスト(UAT)とは
受け入れテストとは、どのようなものなのでしょうか。
実施の目的と、実施範囲の決め方と合わせて解説します。
システムが発注通りかを確認するテスト
受け入れテストとは、外部に発注したシステムが納品されたとき、それがこちら（発注側）の要求通りのものかどうか調査することです。
受け入れテストを実施する際は、そのシステムが実際に運用される場面を想定して、実行環境に近い環境を用意します。
基本的にこのプロセスは、発注した側、つまりシステムを実際に利用する企業がおこないますが、外部企業に委託することも可能です。
ここでは、発注内容に沿った機能が実装されているか、それが問題なく動作するかや、エラーメッセージを見たユーザーが適切な行動をとれるかなども調べていきます。
受け入れテストにはさまざまな呼び方があり、「UAT(User Acceptance Test)」や「検収テスト」、「ユーザー受け入れテスト」とも言われます。
通常は、
「受け入れテスト完了 ＝ 納品物受領」
のタイミングで行い、一連の開発業務の委託の最終段階という位置づけです。
受け入れテストの目的と重要性
受け入れテストは、開発されたシステムが実行環境で、正常に要件通りに動作するか、ユーザーはシステムを快適に使えるかなど確認するもので、開発プロセスの最終段階に位置します。
こうした調査の最大の目的は、開発したシステムが成果物として認められるかを判断することです。
受け入れテストのように、本番環境を想定した作業を十分におこなわないと、納品後に思わぬトラブルが発生してしまいます。
また、受託開発と呼ばれる納品物や成果物を必要とする契約において
「開発が完了した事（契約が満了したこと）を承認する」
というのは、契約上大きな意味があります。
実際に稼働を始めたシステムが正常に動作しないと発覚した場合、発注側の業務に大きな支障が生じますし、開発側も急いで改修業務に当たらなければなりません。
このように、受け入れテストを実施することは、発注・開発の両者にとって大きな意味を持つのです。
受け入れテストの種類
受け入れテストというと、一般的にはシステムやソフトウェアに対して実施するものですが、対象ごとに異なる名称も存在します。
まず「工場受け入れテスト」は、発注した製品が工場内で正常に動作するかを、工場職員が実施するものです。
ここでは、システム面だけでなく、ハードウェアも重要なテスト対象となります。
また、ユーザー自身がテストをおこなう「サイト受け入れテスト」というものもあります。
各機能やUI/UXがユーザーのニーズを満たしているかを調査するもので、製品によってはハードウェア面についてもテストします。
受け入れテストはどこまでやる？
受け入れテストを実施する際、「どこまで調査するか」が問題です。
納品されたシステムに対して、本番環境で想定されるあらゆるケースを網羅すれば、実際にシステムが稼働してから、ある程度の安心を得られます。
しかし、その分だけテスト工程が増えるため、膨大なコストが発生します。
開発側でも正常に稼働するかの調査は実施されるため、二度手間にもなります。
現実的には、十分に満足できるまでおこないたくとも、時間的・金銭的にコストがかけられないことが多いでしょう。
そのため、必要最小限の工程で受け入れテストを済ませたいという要望が生まれます。
このように、受け入れテストの要件を決める際には、稼働後に大きなトラブルが発生しない範囲で、最小限のコストでおこなう必要があります。
受け入れテストとシステムテストの違い
システム開発にはいくつかのプロセスがあり、開発に携わる人でないと、受け入れテストと混同しがちです。
ここでは、特によく間違われる「システムテスト」について、受け入れテストとの違いを解説します。
システムテストとは
「総合テスト」とも呼ばれるシステムテストとは、開発中のシステムが設計通りかを調査するもので、基本的には設計工程におけるミスを発見するためにおこなわれます。
システムテストでは、仕様で定めた機能が不足なく実装されているかを確認する「機能テスト」や、仕様通りの動作をするかを調査する「性能テスト」、システムに設計時に許容した範囲内の負荷がかかった場合に正常に動作するか調べる「負荷テスト」などの工程を経ることで、システムの機能をチェックしていきます。
受け入れテストとの違い
両者の大きな違いは、このプロセスを経て確認したいポイントの違いです。
システムテストは、開発側がシステムの設計を調査するのに対し、受け入れテストは発注側が要望通りのシステムかを調べるのが目的です。
一般的に、システムテストは受け入れテストの前段階、つまりは納品前の最後の工程として位置づけられます。
システムテストは、その後のプロセスの内容を左右する、重要な作業となります。
受け入れテスト以外のテスト
システムテストと同じく、受け入れテストに繋がる重要なテストが存在します。
ここでは、システム開発において大きな意義を持つ「単体テスト」と「結合テスト」、そして、システムの品質を担保する「V字モデル」について解説します。
単体テスト
コンポーネントテストやユニットテストとも呼ばれる「単体テスト」は、システムを実装してから最初に位置するプロセスです。
通常、システム開発は各機能ごとにプログラムを設計し、最後にすべてを組み合わせてひとつの製品とします。
単体テストは、プログラムの結合前に、各機能を独立したものとして、ひとつずつ見ていきます。
単体テストの目的は、それぞれのプログラムが正常に動作するか、バグはないかを詳しくみることです。
単体(コンポーネント)に問題があると、その後の工程に大きな支障が出るため、調査の基礎となる重要な業務なのです。
結合テスト
単体テストを経たプログラムを組み合わせて、正常に動作するかを確認するのが「結合テスト」です。
結合テストの多くはインターフェースにまつわるもので、例えば、ユーザーから入力を受け取る機能と、その内容を照合する機能を連携させたとき、仕様通りの動作をするかといったことが重点的に調査されます。
プログラム単独では問題がなくとも、結合することで不具合が発生することは多々あります。
また、外部システムとの連携についても、それぞれの動作は正常であっても、連携したとたんに上手くいかないといったことも少なくありません。
結合テストは基本的に上位インターフェースから順番に進め、あらゆる組み合わせを想定して調査をおこないます。
結合テストが完了したシステムは、システムテストを経て発注側に渡され、受け入れテストが実施されます。
「V字モデル」とは
開発したシステムについて十分な品質を担保するためには、テスト工程を整理しておかなければなりません。
「V字モデル」は、開発の各上流工程をテスト工程に対応させた表で、計画の設計、要件漏れなどを減らす目的があります。
V字モデルにおいては、要件定義が受け入れテストとシステムテストに、基本設計が結合テストに、詳細設計が単体テストに対応し、細部から全体へテストを進めるようモデリングされています。
受け入れテスト実施時のポイント
受け入れテストは、要件とコストのつり合いを意識しなければなりません。
このプロセスを実施する上では、いくつかのポイントを抑えておく必要があります。
優先度の高い機能からチェック
調査項目を厳選するためには、各機能に重要度を割り振り、優先して調べなければならない箇所を決める必要があります。
受け入れテストをおこなう際は、どの機能が重要なのかを、あらかじめ把握しておくことが大切です。
特に詳しくチェックしておきたいのは、外部システムと連携して動作するか、実行環境で業務シナリオを完遂できるといったポイントです。
業務的影響度の高いものからチェック
前述の優先度の話と繋がりますが、業務的な影響度が高い部分から優先的にチェックすることも重要です。
例えば次のようなものが考えられます。
・決済機能（お金に関連する部分）
・エンドユーザーが使う機能（顧客満足度に影響する部分）
・全社的に利用する機能
・業務が停止する危険性のある機能
・データの登録画面
・問い合わせ対応が多発する事が予想される画面
これらの機能は、実際に運用開始後にバグが見つかった時に、すぐに対応してもらわないと困る様な部分です。
こういった機能は、UATの段階でしっかりとチェックをしておく必要があるでしょう。
反対に、閲覧専用の画面や、データ分析用の画面など、管理者だけが使うような機能は、修正に多少の時間がかかっても問題ないケースが多く、優先度が低いと考えられます。
仕様変更があった箇所に注意
受け入れテストを実施する際に見落としがちなのが、仕様変更がなされた箇所です。
当初の設計から変更された部分はトラブルの温床であるため、重点的にテストしたいところです。
仕様変更が正常になされているか、変更箇所に他の部分が対応できているか、こちらの要望と変更内容が合致しているかなどを確認しましょう。
特に要件定義や設計の段階で、何度も仕様変更したような箇所は、コーディングと設計書にズレが有る事もあるため注意しましょう。
実行環境で実施する
受け入れテストは、システム稼働前の最終プロセスであるため、実行環境で実施することが重要です。
結合テストやシステムテストでは、本番を想定した環境で、開発側が用意したデータを用いておこなわれます。
そのため、いくら前段階で入念に確認をおこなったとしても、本番環境でも100％正常に動作するとは限りません。
大規模なシステムになるほど実行環境での受け入れテストが難しくなりますが、この視点をおろそかにすると、大きな障害の元になってしまいます。
特に、開発者と実際の利用者とで異なる「当たり前」の差は大きいです。
例えば、ファイル名に半角の「.」を使うか否か。
開発者からすると、半角の「.」は拡張子を表すため、ファイル名に入れることはありません。
しかし、パソコンに詳しくない一般ユーザーの場合、ファイル名を日付にして
「2023.1.1.txt」
のような命名をしている場合があります。
（これは実際に過去、生産現場であった事例です）
こういった当たり前の差で、見つからなかったバグが発見される可能性があるため、実際の運用に近い環境でテストするUATは非常に重要なのです。
高品質なシステム開発ならAMELAに
今回は、システムの開発において重要なUATについて見てきました。
UATは、開発を依頼する上で重要な工程ですが、開発を依頼する企業の品質が悪い場合、このUATの工数が膨大になる可能性があります。
当然ですが、バグが多いプログラムほど、UATに時間がかかります。
また、その修正をチェックする必要性もあるので、二度手間になってしまいます。
その1つの原因が「開発者側がしっかりとした結合テスト工数を取っていない」というもの。
開発時にテストが不十分で低品質なプログラムが納品されることは、予算に余裕がないプロジェクトでよくあることです。
そんな経験がある企業様や、これから依頼をする上で不安を感じている企業様は、是非AMELAにご相談ください。
AMELAは、オフショア開発を武器としたシステム開発が得意です。
海外の優秀なエンジニアを安価に参画させる事ができるため、同じ費用でも国内開発に比べて余裕のある体制で開発が行えます。
テストにも十分な工数や人員を割くことができ、結果UATも少なくて済むため、見た目の工数以上にコストパフォーマンスが良い開発が可能です。
是非、一度ご相談頂ければと思います。
