ERPの受入テスト：業務担当者向けUATチェックリスト

ERPの受入テスト（UAT）は、納品されるシステムで合意した業務を実行できるか、業務担当者が確かめる工程です。画面が開くだけでは十分ではありません。受注内容が正しく見えても、在庫の増減や承認状態が間違っている可能性があります。

要件と確認可能な業務結果を結び付けることが目的です。開発側のテストを補うものであり、セキュリティや性能などの技術的な検証を置き換えるものではありません。

対象業務と判定責任者を決める

今回のリリースに含む業務、関係部署、承認できる担当者を一覧にします。権限設定、代表的なテストデータ、外部連携の準備状況も確認してください。対象外の機能を明記すると、追加要望と不具合を混同しにくくなります。

合格となる結果は、業務責任者と開発側が一緒に定義します。開発担当者だけで、日常業務として使えるかを判定しないことが大切です。

開始時のデータ、操作する役割、手順、期待結果、実際の結果、証跡を記録します。画面写真だけでなく、再現に必要な取引番号なども残します。

例として、10個の受注から6個を出荷し、4個が未出荷になるケースを考えます。出荷記録、残数量、在庫移動に加え、適用する承認や請求のルールを期待結果に記載します。分納時の請求方法は企業ごとに異なるため、共通のルールだと決めつけないようにします。

管理されたテスト環境と、利用を認められたデータを使います。本番確認を別途合意した場合を除き、テスト取引が実際の出荷や顧客通知につながらないようにしてください。

不具合には期待した動作、実際との差、業務への影響、再現手順を添えます。見た目の目立ちやすさではなく、業務上の影響で重要度を決め、修正担当と再確認日を設定します。

修正後は失敗したシナリオだけでなく、関係する処理も確認します。出荷数量の計算を直したなら、在庫表示や受注残数量にも影響がないかを確かめます。

リリースを止める問題の基準は、テスト開始前に定めます。未解決事項、回避方法、担当者、対応予定日を判定記録に残してください。デモが成功したことだけで、必要なシナリオの完了や責任者の承認を代替しないようにします。

公開後の問い合わせ窓口と問題報告の手順も確認します。重要な業務が検証できていなければ、対象を絞るか、その部分の開始を延期する判断が必要です。