最終更新日: 2024年2月19日

受け入れテストは、開発されたソフトウェアが発注側の求める通り使えるかをチェックする重要なテストです。ただし、初めて受け入れテストについて学ぶ方は、その他のソフトウェアテストとどう違うのか分かりにくいかもしれません。この記事では受け入れテストとはどういったものかやシステムテストとの違い、効率的に行う方法等を紹介します。

受け入れテストとは

ソフトウェアテストの種類

受け入れテストとは、ソフトウェアが発注側の要求した通りに開発されているか、想定した通りに稼働できるか確認するためのテストです。受け入れテストは基本的に開発側でなく、ソフトウェアの発注側が行います。（発注側が委託した第三者により行われることもあります。）

受け入れテストは英語では「UAT（User Acceptance Test）」と書き、「ユーザー受け入れテスト」「検収テスト」「承認テスト」と呼ばれることもあります。どの呼び方であっても、行われる内容は変わりません。

受け入れテストを行うタイミング

ソフトウェアテストのテストレベル

受け入れテストが行われるのは基本的にリリースの直前であり、ソフトウェアテストのなかでも最後に行われるテストとなることが多いです。ただし、必ずしも受け入れテストが、最後に行われるわけではありません。

たとえば、すでにインストールしているソフトウェア、開発中のソフトウェアと統合する時点で行われることもあります。統合後には、別のソフトウェアテストが実施されるわけです。

その他、拡張予定の新機能に対して受け入れテストが行われることもあります。この場合、拡張した機能と既存機能を合わせたシステムテストが、別途実施されることになります。

システムテストとの違い

システムテストとはソフトウェア全体に関する統合的なテストで、ソフトウェア開発の最終段階で行います。受け入れテストは基本的に発注側が行うのに対し、システムテストを行うのは開発側です。

受け入れテストの目的は飽くまで「要求通りに開発されているかのチェック」であって、不具合を見つけることではありません。また、ソフトウェアに求められる要件を満たしているか確認する、開発側のシステムテストとも異なります。

とはいえ確認すべき機能や事項はほぼ同じなので、テスト内容の違いも大きくありません。そのため違いは分かりにくいですが、目的が別々であることから確認方法や判断基準も微妙に異なることがあります。

受け入れテストのテストベース

テストベースとは、テストの実施内容を具体的にまとめる「テストケース」を作成する際に、その参考資料となるもののことです。たとえばテストケース作成にあたり、仕様書を参考にする場合は、仕様書がテストベースの1つとなります。

受け入れテストの主なテストベースとしてあげられる資料は以下の通りです。

・ソフトウェアに対するユーザーの要求をまとめた「ユーザー要件」
・ユーザーの要求する仕様を満たすのに必要な「システム要件」
・利用者がソフトウェアをどのように使うかまとめた「ユースケース」
・ビジネスプロセス
・ソフトウェア利用時のリスクについてまとめた「リスク分析レポート」

受け入れテストの種類（テストタイプ）

一口に受け入れテストといっても、誰が行うかや目的により複数の種類に分類されます。以下、主な受け入れテストの種類を紹介します。

運用受け入れテスト（運用テスト）

システムの管理者が、システムの運用的に支障がないかを確認するための受け入れテストです。具体的にはバックアップやリストアが可能か、災害時の復旧・セキュリティに問題ないか、ユーザー管理が適切に行えるか等をチェックします。

契約による受け入れテスト

契約書にまとめた内容を満たしているかチェックする種類の受け入れテストです。より具体的には契約書通りの品質を満たしているか、納期等に問題ないかを確認します。

規定による受け入れテスト

ユーザーが該当のソフトウェアを利用するのにあたり、法律・安全基準等の観点で問題ないかチェックするための受け入れテストです。会計・医療・セキュリティ等、取り扱う分野によって異なる法律・基準を考慮する必要があります。

アルファテスト・ベータテスト

実際にソフトウェアを利用するユーザーや既存顧客に試用してもらい、フィードバックを受けるためのテストです。使用感に問題ないかや、実際の利用にあたって不具合がないか等を確認してもらいます。なおアルファテストは開発チーム以外の組織内のユーザーが行い、ベータテストは顧客や潜在顧客によって行われます。

受け入れテストを効率よく進める方法

受け入れテストを行う発注側も、必ずしも受け入れテストに多くの時間を割けるわけではありません。また開発側で十分なテストを行った上で、発注側で似たようなテストをしても無駄という意見もあります。そこで受け入れテストを行う際は、効率を重視される場合が多いです。

受け入れテストは、必要最低限のポイントに焦点をあてて実行することで効率よく完了できます。具体的には、開発側が定める「要件定義」でなく発注側の「要求定義」に基づきテストを設計し、実行するのがよいでしょう。

この場合の「要求定義」とは、ソフトウェアに対して発注側が求める仕様（「～がしたい」）を指します。開発側は要求定義に基づき、ソフトウェアをどのように開発するとよいかの「要件定義」を行うわけです。

たとえば「管理画面で顧客情報を一括更新したい」という、発注側の要求定義があったとします。開発側は要求定義に基づき、「管理画面でのCSVファイルアップロードで、顧客情報の一括更新を実現する」という要件定義を行うわけです。

テストの範囲を要件定義でなく要求定義にすることによって、テストの範囲を必要最低限に絞ることができます。

まとめ

受け入れテストとは、開発されたソフトウェアが発注側の要求を満たしているかチェックするためのテストです。受け入れテストは発注側、もしくは発注側が委託した第三者によって行われます。

受け入れテストが行われるのは、基本的にはソフトウェアをリリースする直前です。（開発中のソフトウェアと統合する場合等、リリース直前に行われないこともあります。）このテストの結果をもってユーザーの利用が開始されることから、重要な役割を担うテストと言えます。

ただし必ずしも発注側が受け入れテストに十分な時間を割けるとは限りません。受け入れテストを効率的に行うためには、発注側の求める要求定義に絞ってテスト設計を行います。