SYSTEM ACCEPTANCE TEST
システム開発の受入テストで確認する7項目
開発会社から「テスト済みです」と納品されても、そのまま検収してよいとは限りません。実際の担当者が、自社の業務を始まりから完了まで進められるかを確かめます。
7項目を確認する先に結論
受入テストは、実際の仕事を一件ずつ通します
たとえば受注管理なら、受注を登録できるだけでは足りません。在庫が足りないときに保留できるか、値引きの承認先が正しいか、出荷後に請求へつながるか、取消時に在庫と請求が戻るかまで確認して、一つの業務が終わります。
毎日使う通常業務と、止まると影響が大きい例外を5〜10件選びます。前提、期待結果、実際の結果、業務影響、再テスト結果を一件ずつ残します。
開発会社は、仕様書や設計書に沿って機能や連携を確認します。発注側の受入テストは、その確認をやり直す作業ではありません。契約・要件と、現場の仕事が同じ結果を指しているかを実務担当者が確かめる作業です。
始める前の準備
先に4つをそろえる
テストを始めてから合否の意味が変わらないように、期間・環境・参加者・記録場所を先に合わせます。
契約上の期間と基準
契約書と合意文書を確認し、テスト期間、合否の通知方法、修正後の再テスト、未完了項目の扱いを共有します。
本番に近い環境と権限
実際の端末・ブラウザ・権限・連携先に近い環境で、担当者、承認者、閲覧者など役割ごとに試します。
業務を知る参加者
普段その仕事をする人が操作します。IT担当者は環境と記録を支え、業務責任者が完了を判断します。
データと記録場所
通常・境界・例外を再現できるデータを用意し、問題はチャットだけで済ませず一つの一覧へ残します。
合否条件は案件ごとに異なります。モデルや一般論ではなく、実際の契約書・要件定義書・設計書と、合意したテスト条件を基準にしてください。
業務シナリオ
機能を、仕事の流れでつなぐ
画面単体では見えない食い違いを、始まり・分岐・連携・完了の順で確かめます。
検収前の確認
受入テストで確認する7項目
自社の仕事へ置き換えやすいよう、各項目に受注管理の確認例を付けています。
- 01
通常業務を始まりから完了まで通す
最も多い処理を、登録、確認、承認、出力まで止めずに進めます。画面ごとの合否ではなく、業務の完了状態まで確認します。
確認例：新規受注を登録し、在庫を引き当て、出荷を確定し、請求対象へ渡せる。 - 02
例外・取消・差戻しを通す
在庫不足、入力誤り、差戻し、注文取消、返品などを確認します。途中状態が残らないか、関連データが正しく戻るかを見ます。
確認例：出荷前に取消すと、引当在庫が戻り、請求対象から外れ、取消理由が履歴に残る。 - 03
権限・承認・代理を役割ごとに試す
担当者、承認者、管理者、閲覧者で、見える情報とできる操作が違うかを確認します。不在時の代理も対象です。
確認例：営業担当は値引きを申請できるが自分では承認できず、承認者だけが確定できる。 - 04
既存・移行データを使う
新規登録だけでなく、移行した顧客、商品、残高、履歴を検索・更新・集計します。文字化け、桁落ち、重複、関連切れを確認します。
確認例：過去履歴のある顧客へ受注を登録し、売掛残高と請求先が正しく表示される。 - 05
外部連携・通知・帳票までつなぐ
会計、在庫、メール、PDF、CSVなど、別の仕組みへ渡るところまで確認します。相手側の内容と再送時の重複も見ます。
確認例：出荷確定後、在庫が減り、請求データが一件だけ作られ、担当者へ通知される。 - 06
締め・大量処理・期限のある仕事を試す
月末締め、一括登録、複数人の同時操作などを試します。途中で止まった場合に、完了と失敗を分けて分かることも確認します。
確認例：月末対象を一括確定し、完了件数と失敗件数を分けて確認できる。 - 07
エラー後の再実行と復旧を確かめる
入力エラー、連携失敗、通信切断を想定します。再実行で二重処理にならず、必要なら元の状態へ戻せることを見ます。
確認例：会計連携が失敗しても対象を識別でき、同じデータを安全に再送できる。
架空の業務例
在庫不足の受注を、請求まで一件通す
顧客事例ではなく、確認方法を示す架空例です。
- 前提
- 顧客Aから商品Xを12個受注。在庫は10個、2個は入荷待ち。10％を超える値引きは責任者承認。
- 操作
- 受注登録 → 在庫確認 → 分納 → 値引き申請 → 承認 → 10個を出荷 → 2個を後日出荷 → 請求確定。
- 期待結果
- 在庫10個だけが先に引き当てられ、2個は入荷待ち。承認前は出荷確定できず、2回の出荷が一つの受注へ紐づく。
- 例外確認
- 1回目の出荷後に残りを取消すと、入荷待ちが解除され、未出荷分は請求されず、取消理由が履歴に残る。
問題の記録
一件ずつ、再テストできる形で残す
「動きません」だけでは再現できません。どのデータで、どこまで進み、何が期待と違い、業務が止まるのかを分けます。要件にない新しい希望は、受入不具合へ混ぜず追加要望として分けます。
- シナリオ名
- 前提データと権限
- 操作手順
- 期待した結果
- 実際の結果
- 業務への影響
- 証拠と対象番号
- 対応担当と期限
- 再テスト結果
- 合格・保留・未完了
検収判断へつなぐ
合格・保留・再テストは、合意済みの基準から決める
- 契約と合意済みの要件・合否基準に照らす
- 日常業務を止めるか、データや権限に問題があるか確認する
- 修正対象と影響範囲を決める
- 修正後は、問題箇所と関連する流れを再テストする
- 未完了、暫定対応、再テスト日、承認者を残して判断する
まず、毎日使う通常業務、売上や請求に関わる流れ、発生すると復旧が難しい例外から5〜10件を選びます。同じ条件で再テストできる記録があれば、受入テストを検収判断に使えます。