受け入れテストとは？発注者・PMが知るべき基本をわかりやすく解説

システム開発を発注した立場のとき、「受け入れテストをお願いします」と言われて戸惑ったことはないでしょうか。

「テストはエンジニアがやるものでは？」と思う方もいるかもしれません。でも受け入れテストは、発注者や業務担当者が主体となって実施するテストです。この工程を正しく理解していないと、リリース直前に「思っていたものと違う」という問題が起きやすくなります。

この記事でわかること

受け入れテスト（Acceptance Testing、またはUAT：User Acceptance Testing）とは、開発側から納品されたシステムを、発注者・利用者側が実際に使ってみて、要件を満たしているかを確認するテストです。

「仕様書に書いた通りに動いているか」「実際の業務で使えるか」を発注側が判断する最後の関門です。受け入れテストに合格したら、発注者がシステムを「受け入れた（受領した）」ことになり、リリースへ進みます。

注文住宅の引き渡し前確認に例えてみます。

ハウスメーカーに家を発注したとします。完成したら、引き渡し前に施主（発注者）が実際に家の中を歩いて確認します。「間取りは図面通りか」「設備は要望通りに設置されているか」「実際に使えるか」を自分の目で確認します。この「施主による最終確認」が受け入れテストにあたります。

ここで「床が傾いている」「コンセントの位置が違う」といった問題が見つかれば、引き渡し前に修正を求めます。これが受け入れテストで問題が見つかった場合の流れです。

大事なのは、施主が確認するのは「施工の技術的な品質」だけでなく、「自分が要望した通りになっているか」という点です。ソフトウェアの受け入れテストも同じく、「発注側の要件が満たされているか」を確認します。

受け入れテストには、主に以下のような関係者が関わります。

受け入れテストの前に、通常は**受入基準（Acceptance Criteria）**を定めておきます。「どの機能が動いていれば合格か」「何件以上のバグがあると不合格か」という基準です。この基準が曖昧なまま進めると、テスト後の合否判断で揉めることがあります。

受け入れテストは開発側がやるものと思っている

受け入れテストの主体は発注者・利用者側です。開発側がシステムテストをして問題ないと判断したとしても、発注側が「自分たちの要件を満たしているか」を確認するのが受け入れテストの目的です。

受入基準を事前に決めていない

受入基準がないと、何があれば合格なのかが曖昧になります。「なんとなく使えればよい」という基準のなさが、「思っていたのと違う」という問題の温床になります。

テストケースを準備していない

受け入れテストも、事前にテストケース（何を、どうやって確認するか）を用意しておく必要があります。準備なしで「とりあえず触ってみる」だけでは、確認漏れが生じます。

バグを見つけることが目的だと思っている

受け入れテストの目的は、「このシステムを受け入れてよいか（使ってよいか）を判断すること」です。バグを発見することも含まれますが、それだけではなく「実際の業務に合っているか」という観点が重要です。

受け入れテストを担当することになった場合、以下の点を事前に確認しておくとスムーズです。

受け入れテストの結果として問題が見つかった場合、すべてのバグを修正してから受け入れることもあれば、軽微な問題は「次のバージョンで修正」という形でリリースを進めることもあります。これは受入基準の設計次第です。

受け入れテストの考え方や、受入基準の設計を体系的に学びたい方には、FEXシリーズのソフトウェアテスト入門講座が参考になります。