受入テストを始める前に揃えたいのは、操作手順だけではありません。誰の業務が、どの状態まで進めば受け入れられるのかを、業務担当者と開発・導入側で共有する必要があります。
この記事では、IT営業や導入担当者が顧客との確認を進めるために、受入テストの準備を整理します。契約上の検収条件や法的効果を判断するものではなく、業務上の確認項目を具体化するための説明です。
受入テストで確かめたいことを揃える
MicrosoftのDynamics 365向けガイドでは、UAT（User Acceptance Testing）を、業務側のニーズや期待を満たすことについて関係者の承認を得る機会と位置付けています。製品固有の実施手順はそのまま他のシステムへ当てはめず、「業務側が何をもって確認済みとするか」を考える参考にできます。MicrosoftのUAT説明
開発側の機能テスト結果と、業務側が使えると判断する材料は、重なる部分もあります。ただし「保存ボタンで登録できる」と「担当者が正しい情報を受け取り、次の作業を完了できる」は確認対象が異なります。既存のテスト結果を参照しつつ、誰が追加で何を見るかを決めましょう。
機能一覧を業務シナリオに組み直す
画面ごとの項目を順に見るだけでなく、開始から終了までの業務の流れを一つ選びます。入力者と承認者が異なる業務なら、役割をまたぐ箇所も含めます。
次は、社内申請システムを想定した仮例です。特定企業で実施したテストではありません。
| 場面 | 操作・条件 | 期待結果として書くこと |
|---|---|---|
| 通常の申請 | 必須項目を入力して提出 | 承認者に届き、申請者が状態を確認できる |
| 入力不足 | 必須項目を空欄にする | 不足箇所が分かり、未完成の申請を提出扱いにしない |
| 差し戻し | 承認者が理由を付けて返す | 申請者が理由を確認し、修正後に再提出できる |
| 対象外の利用者 | 閲覧権限のない役割で開く | 合意した権限仕様どおり、情報が表示されない |
表の期待結果は、実際の要件に合わせて書き換えます。たとえば差し戻し後に申請番号が変わる仕様なら、その前提を共有しておかないと、テスターによって判断が分かれます。
期待結果を決める段階で合意がない項目は、「テストで何となく判断する」状態にせず、要件確認の論点へ戻します。テスト結果と仕様の未決事項を分けることが大切です。
開始前に用意するもの
Azureのテスト計画ガイドは、対象範囲、ケース、担当、日程に加え、開始条件と終了条件を計画へ含める考え方を示しています。Azureのテスト戦略
受入確認では、次の項目を準備表にすると不足を探しやすくなります。
- 対象版と環境：どの版を、どこで確認するか。途中の版変更をどう記録するか。
- テスト用の役割：申請者、承認者など、確認する権限ごとの利用条件。
- データ：通常・不足・境界など、何を入力して確認するか。利用可能なデータかも確認する。
- 業務担当者：操作する人と、期待結果を判断できる人。代理時の扱いも決める。
- 連携先の条件：メールや外部システムを、実接続・代替・対象外のどれで確認するか。
- 記録と連絡先：不具合の報告先、仕様質問の回答者、再確認を行う人。
利用者が操作方法を知らないことによる問題と、システムの不具合は、対応が異なります。必要な操作説明を用意しつつ、「説明がないと業務を進められない」点も使い勝手の論点として残してください。
合格・不合格・未実施を混ぜない
集計では、実施できなかったケースを合格に含めません。「時間が足りなかった」「連携先が利用できなかった」「仕様が未決」のいずれも、何が未確認なのかを残します。
不合格の場合は、再現条件・期待結果・実際の結果・対象版を揃えて報告します。画面だけでは判断できない問題なら、関連する処理やデータの識別情報を、安全に共有できる範囲で添えます。
未解決事項を残して次の工程へ進めるかは、件数だけでは決められません。影響する業務、回避手段、修正予定、確認責任者を整理し、権限を持つ関係者が判断できる状態にします。「軽微」と呼んでも、月次業務を止めるなら扱いを再検討する必要があります。
修正後は、変わった箇所と関連する流れを確かめる
差し戻し機能を直したなら、その場面だけでなく、再提出から承認までの流れに影響がないかを担当者と確認します。すべてのケースを無条件にやり直すのではなく、変更箇所と影響範囲に基づいて再確認を決めます。判定に用いた版と結果を結び付けて保存しましょう。
初回商談で業務や制約を整理する段階なら、IT営業のヒアリング項目も参照できます。導入提案では、機能の説明とあわせて「どの業務を誰が確認するか」を提示すると、受入準備の担当や不足事項を具体的に話し合えます。