ERP受入テストの作り方｜業務シナリオ・期待結果・証跡

ERP受入テストの作り方について、申込や依頼の前に確認しておきたい項目を整理しました。条件を一つずつ照合して、納得できる選択につなげましょう。

図の項目を使い、候補ごとの回答を同じ条件で記録してください。不明点を残したまま進めず、追加費用・契約条件・利用後のサポートまで確認してから最終判断します。

画面単位でなく業務の完了まで確認する

受入テストは、個々のボタンが動くかではなく、業務の開始から必要な結果まで流れるかを利用部門が確かめる工程です。受注、出荷、請求、入金消込のように複数画面や部門にまたがるシナリオを作ります。

各テストには目的、前提データ、実行者、操作手順、期待結果、判定方法を記載します。金額、在庫、伝票状態、承認履歴など、何が一致すれば合格か曖昧にしません。

業務リスクからケースを選ぶ

すべての組合せを試すのは難しいため、金額や出荷に影響する業務、月末処理、法定帳票、権限の強い操作、連携失敗など、失敗時の影響が大きい経路を優先します。

通常処理に加え、返品、取消、差戻し、重複、欠損、上限超過、締め後修正などの例外も含めます。現場担当者へ過去に起きたミスや手作業の回避策を聞くと、実運用で必要なケースが見つかります。

テストデータと証跡を準備する

データは本番と同じ意味を持つようにしつつ、個人情報や取引先情報をそのまま流用しない方法を検討します。代表的な商品、税区分、権限、部門など、シナリオで必要な属性を事前に用意します。

画面のキャプチャ、伝票番号、出力帳票、承認ログなど、再確認できる証跡を保存します。テスト環境のデータ更新や他の利用者の操作で結果が変わらないよう、準備担当と実行時間を管理します。

不具合を分類し、再テストまで追う

不具合の登録では、再現手順、期待結果、実際の結果、影響業務、発生頻度、添付証跡を揃えます。重大度と対応期限を分けて設定し、担当者が修正した後に同じケースと関連ケースを再実行します。

一時的な回避策で合格にする場合は、業務リスク、実施責任者、終了期限、恒久対応の要否を承認記録へ残します。未解決の重大項目があるまま受入れに進むときは、誰がどのリスクを受け入れたか明確にします。

• ケースID・要件ID・業務責任者
• 事前条件・入力データ・操作手順
• 期待結果・判定基準・証跡
• 不具合の重大度・担当・期限
• 修正後の再テスト・承認・残課題

受入れ判断を記録して教育へつなぐ

受入れ判定は、テスト件数の消化率だけでなく、重要業務のシナリオが合格したか、残課題の影響を誰が理解したかで判断します。業務オーナー、情報システム、導入責任者が確認する範囲を分けておきます。

テスト中に見つかった新しい操作や判断基準を教育資料へ反映します。稼働直後に必要なサポートFAQにも、誤操作、問い合わせ先、未解決の制約を残し、テストを現場定着へ結び付けます。

業務シナリオからテストを組み立てる

テストケースは画面項目の確認で終わらず、受注から出荷、請求、入金、会計仕訳まで業務の流れを通して作ります。正常な取引のほか、数量変更、返品、分割納品、締め後訂正、権限不足、取引先の停止など、現場で実際に起きる例外を入れます。各ケースに前提データ、操作担当、入力値、期待結果、証跡の保管先を記載し、別の担当者でも同じ判定を再現できるようにします。

実データを使う必要がある場合は、個人情報や取引機密の扱いを確認し、マスキングやテスト専用データの利用を検討します。テストデータは役割やマスタ状態の違いを網羅し、同じケースを繰り返す際に初期状態へ戻す方法も決めます。会計年度の切替、月末、税区分、複数通貨など、特定時期だけ発生する処理をテスト計画から漏らさないことが重要です。

合否と不具合の優先度をそろえる

合格条件は、期待した業務結果だけでなく、帳票、承認履歴、仕訳、連携先への反映まで定義します。「画面が表示された」だけでは業務が完了したとは言えません。重大度は、業務停止、金額・在庫の誤り、回避手段の有無、対象者数を基準に分類し、リリースを止める不具合と、条件付きで受容できる不具合を事前に区別します。受容判断には責任者、暫定策、解消期限を必須にします。

不具合票には再現手順、発生日時、利用者権限、入力データ、画面やログの証跡、期待値と実績を記録します。修正後は該当ケースを再実行するだけでなく、影響する別機能への回帰テストも行います。ベンダーが修正完了とした内容をそのまま合格にせず、業務担当者が本番に近い環境で再確認します。件数を消化することより、未解決の重大リスクを意思決定者が把握していることが大切です。

利用部門が参加できる実施計画

テスト担当者には通常業務との兼務時間を確認し、繁忙期や締め日を避けた日程を組みます。説明会だけで参加を求めるのではなく、担当者ごとにテストするシナリオと所要時間を割り当て、前日までに環境、権限、データ、連絡先を確認します。操作に慣れていない人も参加する場合は、説明不足を製品の不具合と取り違えないよう、簡潔な手順と質問窓口を用意します。

テスト完了後は、ケースの実施率、合否、重大度別の残件、再テスト予定、利用者教育の課題を一覧で報告します。重要ケースが未実施なら、他のテストの合格率が高くても本番移行の判断材料として不足します。稼働可否の会議では、未解決事項を隠さず、業務影響、回避策、担当、期限を説明し、残リスクを受け入れる人が明確に承認した記録を残します。

テスト完了を証跡で説明する

テスト完了報告には、予定・実施・合格件数、未実施ケース、重大度別の残件、再テスト結果、受容したリスク、承認者を載せます。スクリーンショットやログはケース番号と結び、後から第三者が同じ結果を確認できるよう保管します。リリース後にしか試せない機能やデータが残る場合は、監視方法、暫定手順、担当者、期限を記録し、未確認事項を合格扱いにしないことが重要です。