UAT(受け入れテスト)とは?実施方法や流れを徹底解説

UATとは

UAT(受け入れテスト)とは、本番に近い環境でシステムが要求通りに運用できるかを検証することです。システム開発では、問題点の発見や正常な動作を確認するためにさまざまなテストを実行します。その中でも、工程の最後に行われるのがUATです。

本記事ではUATの目的や他のテストとの違い、具体的な実施方法や手順、課題点などを解説します。

UAT(受け入れテスト)とは?

UAT(受け入れテスト)とはUser Acceptance Testingの略称で、発注者側であるエンドユーザーが実施する最終テストのことです。UATが問題なく終わった段階で製品がリリースされるため、非常に重要です。テスト自体が不十分であった場合は、不具合が残ったままサービスが開始される恐れがあるため、細かい部分まで網羅して検証する必要があります。

また、万が一UATで不具合が見つかった場合、すぐに問題を分析して修正を行わなければいけません。その際には、前工程であるシステムテストや結合テストが再度行われることもあります。

UAT(受け入れテスト)の主な目的

UATの主な目的は、運用時における機能の動作確認と発注者のニーズを満たしているかの確認です。

UATの前段階までは開発者によるテストが行われますが、UATでは、発注者側が実際に運用した時にシステム自体に不具合がなく適切に動作するかを確認します。

また、発注者にテストしてもらうことで、業務フローに沿って正しく機能するかを検証したり、使いやすいインターフェースになっているかなどを調査・確認したりすることも目的のひとつです。

納品後に「注文したシステムと違う」「運用時に大きなミスが発覚した」「使い勝手がよくない」といったトラブルを回避でき、リリース後の問題発生のリスクを低減できます。

UAT(受け入れテスト)と他のテストの違い

システム開発の工程では、UAT以外にもさまざまなテストがあります。ここではそれぞれのテストとUATの違いを解説します。

コンポーネントテストとの違い

開発の初期段階で行われます。コンポーネントは、ソフトウェアのプログラムのひとつの構成単位のことで、プログラムの部品を指します。これらの部品がそれぞれ正しく機能するかを、コンポーネントやモジュールが完成した段階で検証します。

実施の際にはテスト環境を作成して関数やクラスのメソッドを呼び出し、コードが期待通りに動作するかを確認します。ここで問題が起きた場合はプログラムの修正を行い、正常に動作するまで何度もテストを行わなければいけません。

すべてのコンポーネントが設計通り正しく機能していることを確認できれば完了です。

結合テストとの違い

結合テスト(インテグレーションテスト)は、複数のコンポーネントを結合して正しく動作するかを確認します。前段階のコンポーネントテストで個々の動作確認が完了した後、ここでは複数のコンポーネントやモジュールが連携した際に正しく動作するかを検証するのが目的です。

個々のコンポーネントが単体では正常に動作していても、結合された際に問題が発生する場合があります。そのため、実施時にはテストケースを作成し、ケースに基づいた動作が正常に行われているかを確認しましょう。問題があった場合は修正を行い、システムが正常に動作するまで確認します。

システムテストとの違い

結合されたシステムが設計通りに機能して、期待された通りの品質が確保されているかを検証します。結合テストの後に行い、システム全体の動作を確認します。

これまでと同様に、実施する際はテストケースを作成してケースに沿った動作が正しく行われているかをチェックします。

このとき開発目的の主となる機能と、セキュリティテストやユーザビリティテストといったようなシステム自体の動作に関する非機能テストを行い、全体評価をして完了です。

これらが正常に終了すれば、最終的に発注者側が検証するUATが行われます。そのためUATが行われる段階では、開発側によってシステム全体に問題がないことが確認されているはずです。

UAT(受け入れテスト)の6つの実施方法

UATの種類は機能の適合性やセキュリティ、ユーザビリティなど、確認すべき目的に応じて一般的に6種類に分けられます。

機能テスト

動作が問題なく行われているかを評価します。これは、UATの中で最も基本的かつ重要な項目で、発注者の希望に沿ったシステムになっているかを確認します。

そのため、ユーザーが実際に行う業務フローに基づいてシナリオを作成し、そのシナリオを元に動作確認を行いましょう。

また、正常なケースだけでなく、エラーや不正入力があった際にどのような動作をするのかも確認します。これによって、発注者が定義した仕様通りに機能が適切に動作しているか、設計書通りになっているかが検証できるでしょう。

問題が発見された場合は、関係者にフィードバックを行って修正を行い、修正後は再度問題がないかを確認します。

性能テスト

構築されたシステムが要求されたパフォーマンスを正常に満たすかを、実際の運用環境に近い条件下で行います。主に「システムの応答時間」「処理速度」「負荷による耐性」などを確認してボトルネックを特定し、解消することが目的です。

ここでもシナリオケースを元にテストを進めますが、さまざまな負荷をかけることでパフォーマンスに問題がないかを確認します。

例えば、システムに同時に複数のアクセスを集中させ、システムがダウンしないか、トランザクションの処理速度やシステムの応答時間に問題がないかなどを確認したり、極限の負荷をかけてシステムの耐性を確認したりします。実施の際は負荷テストツールを使用して検証する方法も一案です。

疎通テスト

システム間の連携や通信が正常に行われているかを検証します。開発段階でも疎通テストが行われますが、ここではシステム内の異なるコンポーネント間でデータやメッセージが正常にやりとりされているかの確認が目的です。

「リクエストとレスポンスが正常に行われているか」、「動作時間に問題はないか」など、ユーザー視点でシステム間の連携に問題がないかをチェックします。基本的にUATの時点では確認されている項目も多くあります。

回帰テスト

システムの変更や修正後に行います。そのため、基本的に開発段階や運用後にシステム変更が行われたり、修正が行われたりした際に実行しますが、ここまでで大きな問題が発生して修正が行われた場合は、回帰テストが行われることもあります。

回帰テストでは、システムの修正後に既存の機能に影響がないかを調べます。修正後に他の部分がこれまでと変わりなく動作するかや、新機能の追加や不具合修正によって、意図せず他の機能に影響を与えていないか確認することが重要です。

この確認はツールで自動化して工数を削減でき、前段階で回帰テストを行うことでよりスムーズに実施できます。

ユーザビリティテスト

UI(ユーザーインターフェイス)テストは、効率的に業務が遂行できるかを確認するために発注者側であるユーザーが行います。

実際に使用してみてシステムが直感的に操作できるか、操作性に問題がないかを評価します。これは運用時の使用感を確かめるものなので、ユーザーに課題を提示した上でリラックスして使用してもらうことが重要です。

「使いやすいかどうか」「どの部分が使いづらかったか」など、そのときのユーザーの行動や発言を記録して問題点を洗い出します。また、アイトラッカーと呼ばれる視線追跡装置など、特殊な機材を用いて行うこともあります。これによりユーザーがどこを見て操作したかを、システムで把握することが可能です。

セキュリティテスト

システムの脆弱性を検出してデータを保護するために、開発段階から運用時まで段階的に行います。UATではユーザーが使用する際にシステムの安全性が確保されているかを確認します。

例えば、認証機能が付いている場合は、ユーザーを正しく認証し、さらにはアクセス権限が適切に付与されているかが着目したいポイントです。

システムデータには、重要な個人情報が含まれていることもあるため、暗号化によってデータが保護されているかも確認すると信頼性が担保できます。

また、脆弱性を検出するためのシステムスキャンや、外部からのさまざまな攻撃をエミュレートしてシステムの防御力を測るペネトレーションテストも効果的です。

UAT(受け入れテスト)を実施する流れ

UAT(受け入れテスト)は以下のような流れで実施します。

1.テストの計画を作成する

最初にUATを行う目的を明確にして、次に業務範囲やテスト開始日と終了日、必要なリソースを決めます。

ここで重要なのが、システムがビジネス・ユーザー要件を満たしているかを確認するために、テスト範囲を具体的に決めることです。すべてをテストするのが理想ですが、限られた時間とリソースで行うことが多いUATにおいては、発注者側の要求定義にもとづき、特に重要な機能や高リスクの領域について重点的に行うのがよいでしょう。

また、ユーザー視点によるブラックボックステストや開発者側の視点によるホワイトボックステストなど、どのような視点で行うかも決めなければいけません。

さらに、発注者の要件をもとに何をもって合格とするのかを明確にし、合格基準を定義しておきます。

これらが決定したら、テストの開始日と終了日を決めます。「テストケース作成完了」「テスト実施完了」「バグ修正完了」といったマイルストーンを設定し、リソースを割り当てます。テストチームの編成が完了したら、テストケースを作成し、テストデータの準備に入りましょう。

2.環境を構築する

システムのリリースは、UATの実施後です。そのため、実際の運用環境を忠実に再現して環境を構築することが重要です。

基本的には本番環境と同じ「ソフトウェアバージョン」「データベース構成」「ネットワーク設定」でテストを行います。テストデータは、実際の運用データを模し、業務の流れを設定したシナリオを準備し、データ量も本番環境と同じ分量を用意します。そうすることで、開発中には気づけなかった細かな問題点が発見できるでしょう。

3.テストを実施する

テストの実施にあたっては、連絡フローや検証結果の共有などの管理表を作成し、無駄なくスムーズな運用ができるようにしておきます。その上で実際のユーザーが、作成されたテストケースに従ってシステムの機能や使いやすさなどのレビューを行います。

問題を発見した場合は、問題の詳細、再現手順、問題の範囲などを報告しましょう。報告を受けた開発チームは、確認後システムのバグや不具合を修正します。

全てのテストが完了したら、ステークホルダーの最終承認を経てUATが完了です。

UAT(受け入れテスト)を実施する際のコツ

UATはリリース前の最終確認をするもので非常に重要な工程です。ここで漏れがあると運用時に大きな問題が発生することもあるので、注意深く検証しなければいけません。リスクを低減するためにも、実施のコツを確認しておくことをおすすめします。

優先順位を決めてテストを実施する

UATでは、全ての項目をテストするのは膨大な時間とリソースを必要とするため、現実的ではありません。

確認の優先度を決めてテストを行いましょう。

優先順位を決めることで、以下のメリットが生まれます。

  • リソースの最適化
  • リリース後の問題発生時のリスク軽減
  • ステークホルダーの満足度向上
  • 早期フィードバックが可能

例えば個人情報や企業情報を扱う際に、セキュリティ上の問題があると発注した企業が大きな損害を被ることがあります。そのため、セキュリティ上のバグが発生しそうな箇所を優先的にテストケースに組み込むことで、リリース後のシリアスな問題を防げます。

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

UATは実際のネットワーク環境や、実際のデータで行います。商用環境とほぼ同じ状態でUATを行うことで、以下のようなメリットがあります。

  • 運用時と同じ状況をユーザーが体験することで、本番環境とほぼ同じフィードバックが得られる
  • 商用環境に移行した際に発生するバグを防げる
  • 実際の環境に近いシステムのパフォーマンスを評価できる
  • 発注者側の満足度を向上できる

開発環境でのデータは簡易的・特性が異なるなど本番環境との差異があります。

そのため、実際に運用してみるとテスト環境では発生しなかった問題が発生することも考えられます。商用環境に近い状態でテストを行えばリリース前に問題を発見でき、本番移行前に修正・変更を行えるでしょう。

また、リリース時とほぼ同じ環境でユーザーに確認してもらえるので、発注者のリアルな意見やコメントを受け取れます。

連携システムの挙動を確認する

UAT実施時には他のシステムと連携した際、正しく機能しているかを確認することも重要です。エンドツーエンドでの機能性をテストすることで、システム全体の一貫性が確保できます。

また、送受信が正しく行われているか、エラー処理が正しく機能しているか、エラーの表示が一般ユーザーに理解できるかなど細かい点まで確認します。

そのほかにもパフォーマンスや処理時間は適切か、取り込みのタイミングはどうか、各データ項目は正しくセットされるかなども注意深く観察しておきましょう。

UAT(受け入れテスト)は誰がやるべき?

UATはユーザー目線で行うテストであり、本番環境で実際に使用する発注者側が実施するべきテストです。

実際にはビジネスオーナーや各部門の管理者、現場の担当者、業務プロセスに精通した担当者が行うことで、より具体的な業務フローに適したテストができ、本番環境での問題も発見しやすくなります。

開発者側もテストに参加することで、何らかのトラブルがあった際は迅速に対応できます。

UAT(受け入れテスト)の課題・注意点

UATの課題であげられるのは、リソースや十分な時間の確保です。UATは開発プロジェクトの最後の段階で実施されるため、前段階で問題が発生するとスケジュールが遅延し、UATのための時間が圧迫されます。

しかしUATは品質の担保やユーザー目線でのスムーズな運用を最終確認する重要なテストです。時間がないことを理由にUATが不十分であると、リリース後に問題が発生するリスクが高まります。

プロジェクト全体のスケジュールを立てる際は、UATに十分な時間を確保することが重要です。

まとめ

UATは、システム開発の最終段階で、実際に利用する発注者側が行うテストです。UATでは本番の運用環境やデータを用いてテストを行います。これにより、開発環境では発見できなかった不具合やバグを見つけ出し、リリース前に問題を解決できるでしょう。

また、ユーザー目線で使い勝手や機能の検証ができるため、多くの企業がUATを重視しています。FLEXY(フレキシー)では、システム開発からUATの計画や推進を行うものまで、さまざまなUAT関連の案件を取り扱っています。システム開発に関わるテストの経験を活かしたい方は、ぜひご活用ください。

FLEXYサービスを見る

LINEでフリーランスの案件情報や最新Tipsを受け取る

FLEXYとはABOUT FLEXY

『FLEXY』はエンジニア・デザイナー・CTO・技術顧問を中心に
週1~5日のさまざまな案件を紹介するサービスです