受け入れテストとは

受け入れテストとは

完成したシステムを発注側が操作し、業務で利用できる状態かどうかを確認するテストです。
操作するのは開発会社ではなく、システムを日々使う業務担当者です。
受注から出荷まで、申請から承認までといった業務の流れを、本番に近いデータで最後まで実行して確認します。
業務担当者が行うこの形をUAT（User Acceptance Testing、ユーザー受け入れテスト）と呼びます。

性能やバックアップのような運用面の確認を受け入れテストに含めることもあり、その場合は情シスなどの運用担当者が担い、開発会社の技術者が支援することもあります。

新築の住宅の引き渡し前に、入居者が自分の家具の寸法と生活の動線で部屋を確認する作業に近いです。
図面との適合は施工側が確認済みでも、実際の生活に適するかは入居者でなければ確認できません。

受け入れテストの結果をもとに、発注側が納品物を受領するかを決定する契約上の手続きが検収です。

システムテストとの違い

開発会社は納品の前に、システム全体が仕様書どおりに動作するかをシステムテストで確認します。
受け入れテストとの違いは誰が何を基準に確認するかです。

観点	システムテスト	受け入れテスト
実施する人	開発会社のテスト担当者	発注側の業務担当者
確認の基準	設計書・仕様書	業務の手順と要件定義書
使用するデータ	開発会社が作成したテスト用のデータ	本番に近いデータ
検出される問題	仕様書どおりに動作しない不具合	仕様書に記載がなく業務で利用できない箇所

担い手を別にする理由はテストの独立性にあります。
独立性はテストする人とテスト対象を作成した人の隔たりの度合いを指します。
ソフトウェアテスト技術者の資格を運営する団体がJSTQB（Japan Software Testing Qualifications Board）です。
資格試験の出題範囲はFoundation Levelシラバスとして公開されています。
このシラバスはほとんどのプロジェクトについて、独立性の水準が異なる複数の担い手でテストするのが最善としています。
その例はシステムテストを担うテストチームと、受け入れテストを担うビジネス側の代表者です。

同じシラバスは受け入れテストの目的を、システムがユーザーのビジネスニーズを満たし、稼働の準備ができていることの確認と定義しています。

なぜ必要か

仕様書に記述できるのは業務の一部だけです。
例外的な取引、月末だけの手順、担当者が経験で補完している判断は、要件定義の段階で欠落しやすい部分です。
開発会社は仕様書を基準にテストするため、仕様書から欠落した業務は開発会社のテストを全件通過しても発見できません。

デジタル庁のデジタル・ガバメント推進標準ガイドラインも、発注側が開発事業者の支援のもとで、本番稼働時に近いテストデータによる受け入れテストを行うとしています。
同ガイドラインは設定した品質基準を満たすことを本番移行の条件の1つにしています。

検出される問題は2種類ある

受け入れテストの指摘は扱いの異なる2種類に分類できます。

• 仕様に反する不具合: 修正は開発会社の責任になる。請負なら検収の合否にも関係する
• 仕様どおりだが業務で利用できない問題: 変更の依頼として処理し、費用と稼働日を別に合意する

IPA（情報処理推進機構）の情報システム・モデル取引・契約書のように、検収は仕様書との適合で合否を判定する契約が一般的です。
この契約では仕様どおりの成果物は合格になるため、業務で利用できない問題を理由に検収を拒否すると、開発会社との紛争に発展しやすくなります。
仕様どおりだが業務で利用できない問題を減少させるため、発注側は要件定義と設計の段階で、業務担当者に業務シナリオで画面を確認してもらいます。

効果とコスト

効果は次のとおりです。

• 業務の流れの途中で作業が停止する箇所を、稼働後でなく稼働前に発見できる
• 稼働後の問合せや手作業での補正が減少し、立ち上げ期の混乱が軽減される
• 稼働日までに業務担当者が操作に習熟し、利用者向けの研修としても機能する
• 指摘を一覧にして、検収の判断材料として開発会社に提示できる

コストとリスクは業務担当者の時間だけではありません。

• 業務担当者の時間を数週間にわたって確保し、その間の通常業務はほかの人が代行する
• 確認用の業務シナリオと期待する結果を、発注側が開発の途中から作成する
• テスト環境の構築と本番に近いデータの用意に費用がかかる。データ移行の予行と一体で実施すると準備の手間を削減できる
• 本番に近いデータを使用するには、個人情報の加工や持ち出しの手続きが必要になる
• 開発会社による問合せ対応や修正の待機が、請負の範囲外として別料金になることがある
• 稼働後の改修のたびに同じ確認が発生するため、シナリオを保管して保守の段階でも再利用する

人数と期間の配分

業務の流れごとに、その業務を日常的に行っている担当者を1〜2人は配置します。
人数より、例外的な処理を熟知した担当者の有無が品質を左右します。

業務シナリオの数と担当者が確認に使用できる時間から、確認に必要な期間を逆算します。
目安は小規模な改修なら1〜2週間、業務全体に関係するシステムなら数週間から1か月程度です。
基幹業務システムの刷新では、修正後の再確認を数回繰り返すため1〜3か月を想定します。
担当者が通常業務と兼務する場合は、業務時間の半分程度を確認に使用できる前提で見積もり、不足するなら期間を延長するか人を追加します。

期間には指摘の修正と再確認の時間も含め、契約で定める検収の期間内に完了させます。

業務シナリオは要件定義の後から開発の途中までに作成します。
中規模の業務システムなら主要な業務の流れと例外の流れの合計で数十本程度が目安です。
納品後に作成を開始すると検収の期間の多くがシナリオの作成で消費されます。

開発会社に委託してよいか

シナリオの作成支援やテスト環境の準備は委託してよいですが、操作して合否を決定する役割は発注側が担うべきです。
開発会社は仕様書を基準に確認するため、代行させるとシステムテストの繰り返しになり、仕様書から欠落した業務の問題を発見できません。
業務担当者の時間をどうしても確保できない場合は、確認する業務の範囲を限定してでも本人に操作してもらうほうが、全範囲を代行させるより有効です。

不具合が多数発生したら稼働を延期すべきか

業務を停止させる不具合が未解決なら延期すべきです。
画面の文言や操作の手間のように回避の方法がある指摘は、修正の期限を設定し、稼働後に対応できます。
この区別は次の3点として定め、受け入れテストの開始前に、受け入れテストの計画書や検収の条件を定める文書で発注側が開発会社と合意しておきます。

• 合格の基準
• 不具合の重大度の区分
• 受け入れテストを開始・中断する条件

合意がないと延期の可否はその場の交渉次第になります。

JSTQBの2018年版のシラバスは、受け入れテストで多数の欠陥を検出する事態を重要なプロジェクトリスクに該当し得るものとしています。
多数の不具合は開発会社のシステムテストの不足を示す可能性が高く、その場合は受け入れテストを中断して開発会社に再テストを求めます。

受け入れテストの確認範囲を限定してよい案件

• SaaS（Software as a Service）を標準の機能のまま導入する場合は、自社の業務で使用する画面と設定の確認に限定してよい
• 画面の文言変更や帳票の項目追加のような小規模な改修は、変更した箇所と前後の業務の流れの確認に限定してよい
• 試作品で効果を検証する段階では、業務の流れ全体を確認しなくてよい

反対に、基幹業務システムの刷新、データ移行を伴う刷新、請負で一括発注する高額な案件では厚く行います。

合格しても確認できない処理

受け入れテストで確認できるのは、期間中に実行した業務の流れだけです。
月末の締めや年1回の決算処理、大量のデータでの性能は、稼働後に初めて判明することがあります。
こうした処理は新旧のシステムを同時に稼働させる並行稼働で確認するか、不具合の扱いを検収の条件として契約で定めておきます。