2025.02.13
受け入れテスト（UAT：User Acceptance Test）は、システムの稼働直前に行うことが多いテストです。
システムがトラブルなくスムーズに運用できるかに影響する重要なテストですが、十分な時間をかけられないことも多いです。
限られた時間の中で、効率良く受け入れテストを実施するためには、どのようにすれば良いのか、お悩みの方もいらっしゃるのではないでしょうか。
そこで今回は、受け入れテストの基礎知識と、受け入れテストの効率化を図るためのポイントをご紹介します。
- もくじ
1．受け入れテスト(UAT)とは？
受け入れテストとは、対象のソフトウェアがユーザーの要求を満たしているのか公式に確認し、受け入れの判定・承認をするテストです。
行われるタイミングは基本的にリリースの直前でソフトウェアテストの中でも最後に行われることが多いです。
JSTQB認定テスト技術者資格が公開している「ソフトウェアテスト標準用語集 日本語版 Version 2.3.J02」では以下のように定義されています。
受け入れテスト（acceptance testing）：
システムが、ユーザのニーズ、要件、ビジネスプロセスを満足するかをチェックするための公式なテスト。このテストにより、システムが受け入れ基準を満たしているかどうかを判定したり、ユーザ、顧客、その他の認可団体がシステムを受け入れるかどうかを判定したりすることができる。
引用元:ソフトウェアテスト標準用語集 日本語版 Version 2.3.J02
他にも、受け入れテストには「工場受け入れテスト」と「サイト受け入れテスト」という種類があり、以下のように定義されています。
工場受け入れテスト（factory acceptance testing）：
コンポーネント又はシステムが要件を満たすかどうかを確認するために、製品開発の場所で供給者組織の従業員により実行される受け入れテスト。要件には、ソフトウェア要件だけでなく、ハードウェア要件も含む。
サイト受け入れテスト（site acceptance testing）：
ユーザや顧客が自分のサイトで実施する受け入れテスト。コンポーネントやシステムが、ユーザや顧客のニーズを満たしているかどうか、ユーザや顧客のビジネスプロセスに適合するかを判定するために実施する。通常、ソフトウェアだけでなく、ハードウェアも含める。
引用元:ソフトウェアテスト標準用語集 日本語版 Version 2.3.J02
本記事では、システムの稼働直前に行う「受け入れテスト（acceptance testing）」を例に取って解説していきます。
2．受け入れテストは「どこまでやるか」が悩みどころ
受け入れテストの悩みどころとして、「受け入れテストをどこまでやるか」というものがあります。
外注したシステムを、発注元できっちりテスト設計して受け入れテストを行う場合は、品質面のケアはある程度確保できるかもしれませんが、テストケースが多くなってコストがかさみます。
また、外注先でテストを実施する場合、テスト済のものに対して、受け入れテストでまた同じようなことを実施すると二度手間になってしまいます。
さらに、現実問題として、受け入れテストに十分な時間を割ける余裕が無い、という状況にあるところも多いです。
そのため、受け入れテストの件数を絞って出来るだけ少なくしたい、という要求が生じることになります。
「出来るだけしっかりテストしたい」「出来るだけテストにかける時間は少なくしたい」この相反した要求に対し、優先度を考えながらテスト実施していくことが重要です。
3．受け入れテストで考慮すべき３つのポイント
受け入れテストでは「どんなシチュエーションで、何を目的に行うか」を考慮することが大切です。
ここで考えるシチュエーションは、「システムの稼働直前に行う受け入れテスト」だとして、リスク管理を軸にして考えたときに気を付けるべきポイントをご紹介します。
3-1 特に重要な機能を優先してテストする
まず一つ目のポイントは「重要な機能を優先してテストする」ことです。
今回の「システムの稼働直前」というシチュエーションでは、全ての機能を念入りにチェックする時間の余裕がないことが多いです。
そのため、どの機能をテストするのか、という観点に立ち、「特に重要な機能を優先してテストする」ことが最優先となります。そのシステムの基幹的な機能、絶対に不具合を出してはならない機能などの軸を定め、それを関係者と合意形成することが必要です。
「特に重要な機能」を定めたら、次に、それをどんな条件でテストするかを決めることが必要になります。
「大きな漏れ抜けが無いことを確認する」という観点で、通常の利用状況はもちろん、例えば定期的なイベント日などをテスト条件に採用することが望ましいでしょう。
ここでは、「特に重要な機能が、通常の使い方なのに誤動作してしまい、致命的な事態になってしまうようなリスクを軽減させる」というスタンスで実行することがポイントとなります。
3-2 仕様変更した機能とその周辺機能を優先してテストする
ソフトウェア開発で難しいものの一つとして「仕様変更」があります。「仕様変更した機能とその周辺機能を優先してテストをする」ことも大切なポイントとなります。
なぜなら、開発の途中で仕様を変更すると、開発側としては限られた時間の中でどのように機能を実装するかに傾いてしまい、設計変更が既存の設計部分への考慮漏れや対処漏れを生じさせてしまうことがあるからです。
また、構成管理のミスで、仕様変更に対処済のバージョンでなく、誤って異なるバージョンをリリースしてしまうことも可能性としてはゼロではありません。
これを踏まえて、ユーザーの目線で、仕様変更した機能がリクエストどおりに実装されているか、その周辺に悪影響が及んでいないかを確認すると効果的です。
ここでは「仕様変更に関連した不具合が多いため、そのリスクを軽減させる」というスタンスでテストを行うことがポイントとなります。
3-3 実環境と実データでテストする
受け入れテストをする際は「実際に運用する環境で、実際に扱うデータを使うこと」を心がけましょう。
なぜなら、外注先では、疑似環境や疑似データを使って開発・テストを行うことが多く、最終リリース前に本番環境に移行する処理漏れが発生しやすいからです。
例えば、別のシステムに接続する機能があったとします。開発中は疑似の接続先をシミュレータに設定していますが、最終リリースでは本番の接続先に書き換える必要があります。
しかし、これをうっかり漏らしてしまうケースも多いです。こうなってはその機能は絶対に誤動作してしまいます。
こういった処理漏れを防ぐためにも、開発環境と実環境の違いに着目し、そこに絞って受け入れテストを実施するということが効果的です。
「疑似環境から本番環境に移行した際の処理漏れのリスクを軽減させる」という意識をもってテストを行いましょう。
4．「受け入れテストをするから安心」というわけではない
ここまで、受け入れテストのポイントを紹介させていただきましたが、「受け入れテストをするから絶対安心」というわけではありません。
なぜなら、「受け入れテスト」の対象から外れたものは、システムの稼働直前よりもっと前のフェーズで検証されていることが前提となっているからです。
もし、前のフェーズで適切なテスト実施がされていない場合は、受け入れテストを実施しても不具合や欠陥が残ったままになってしまいます。
そのため、品質の高いシステムをリリースするためには、受け入れテストを行う以外にも、以下のような対策をすることが重要です。
- 開発側で行うテストの計画を関係者の中で合意し、途中経過をモニタリングする
- 開発側で行うホワイトボックステストの計画を立案してもらい、それを実施したエビデンスと分析結果を示してもらうことを受け入れ条件にする
- 使い勝手の良さ／悪さを検証するユーザビリティテストを早い段階で行う
受け入れテストを部分的に切り出して考えるのではなく、発注する機能の品質管理・進捗管理の全体を考え、その中で、受け入れテストの役割をデザインするのが大切です。
まとめ
受け入れテストとは、対象のソフトウェアがユーザーの要求を満たしているのか公式に確認し、受け入れの判定・承認をするテストのことです。
「システムの稼働直前に行う受け入れテスト」を例に取ると、考慮すべきポイントは、ソフトウェア開発の品質管理・進捗管理の全体を考えて、その中で、どんなシチュエーションで何を目的に受け入れテストを行うか、ということになります。
何事においても言えることですが、「どうやるか」よりも先に、「何のために何をやるのか」という目的が大切です。
受け入れテストをする際は、状況にあった目的や方法で実施することを心がけましょう。
