受入テストの進め方：発注側が用意するテストケースと検収の基準

受入テストとは、開発会社から納品されたシステムが、自分たちの業務で本当に使えるかを発注側が確かめるテストです。開発会社も納品前にテストを行いますが、それは主に「仕様どおりに作れているか」を確かめるものです。受入テストは、それとは別に「この仕様で業務が回るか」を発注側の目で確かめる工程であり、検収の可否を判断する根拠になります。

結論から言うと、受入テストを成功させる鍵は三つです。業務シナリオに沿ったテストケースを発注側で用意すること、合格・不合格の基準をテスト開始前に開発会社と合意しておくこと、そして実際に使う現場の担当者をテストに参加させることです。この三つがそろえば、検収後に「使えないことが分かった」という事態の多くを防げます。

この記事は、システム開発を外注していて、初めて受入テストを担当する発注側の担当者に向けて書いています。受入テストの位置づけ、準備から検収判断までの手順、テストケースの作り方、合否基準の決め方、よくある失敗とその避け方を、具体的なチェックリストとともに説明します。

受入テストとは：開発会社のテストとの違い

システム開発では、工程ごとにいくつかのテストが行われます。開発会社が行う単体テスト、結合テスト、総合テスト（システムテスト）と、発注側が行う受入テストの関係を整理すると、次のようになります。

開発会社のテストは、設計書を正しいものとして、それと一致するかを確かめます。そのため、設計書そのものに業務とのずれがあった場合、開発会社のテストでは見つかりません。たとえば「月末締めの請求で、締め日が土日にかかるときの扱い」が設計書に書かれていなければ、開発会社のテストはその場面を確かめないままになります。

受入テストは、こうした「書かれていなかったこと」「業務の現場でしか分からないこと」を見つける最後の機会です。ここで見つけられなかった問題は、本番運用が始まってから、利用者や顧客の前で表面化します。

受入テストの全体の流れ

受入テストは、テスト期間の数日だけで終わる作業ではありません。準備は開発の中盤から始める必要があります。全体の流れは次のとおりです。

1. 受入テストの計画を立てる：テストの範囲、期間、参加者、環境、合否基準を決めます。開発会社の総合テストが始まる前には固めておきます。
2. テストケースを作る：業務シナリオをもとに、何をどう操作し、どういう結果になれば合格かを書き出します。
3. テストデータを用意する：実際の業務に近いデータを準備します。本番の個人情報をそのまま使わない工夫も必要です。
4. テスト環境を確認する：本番に近い環境で、必要なアカウントや権限、外部連携が使える状態かを確認します。
5. テストを実施し、結果を記録する：テストケースごとに合否と気づいた点を記録します。
6. 不具合を報告し、修正を確認する：不具合を開発会社に報告し、修正版で再テストします。
7. 検収の可否を判断する：合否基準に照らして、検収するか、条件付きで検収するか、不合格とするかを決めます。

この中で特に時間がかかるのは、2のテストケース作成と3のテストデータ準備です。開発会社から「来週から受入テストをお願いします」と言われてから慌てて準備しても間に合いません。要件定義が終わった段階で、受入テストのスケジュールと担当者を決めておきましょう。

受入テストの役割分担

受入テストを円滑に進めるには、発注側の中で役割を分けておくことが大切です。一人の担当者がすべてを抱えると、テストの実施と不具合のやり取りに追われ、判断が遅れます。

• 受入テスト責任者：計画を立て、合否を最終判断する人。検収の可否を社内に説明する立場でもあります。
• 業務ごとのテスト担当者：営業、経理、物流など、それぞれの業務を実際に担当している人。担当業務のシナリオを実行し、結果を記録します。
• 取りまとめ役：不具合や気づいた点を一覧に集約し、重複を整理して開発会社に伝える人。責任者が兼ねてもかまいません。
• 開発会社の窓口：問い合わせへの回答、修正版の提供、テスト環境の不具合対応を担います。開発会社側の担当者を明確にしてもらいます。

役割と連絡の流れを最初に決めておくと、テスト期間中に「誰に聞けばよいか分からない」という停滞を防げます。

業務シナリオからテストケースを作る

受入テストのテストケースは、画面ごとの操作確認ではなく、業務の流れに沿って作るのが基本です。開発会社のテストが画面や機能単位で行われるのに対して、受入テストでは「ある業務を最初から最後まで通して実行できるか」を確かめます。

業務シナリオの洗い出し方

まず、システムを使って行う業務を一覧にします。業務フロー図があればそれを使い、なければ「誰が、いつ、何のきっかけで、何をするか」を書き出します。たとえば受発注システムなら、「顧客から注文を受けて登録する」「在庫を引き当てて出荷指示を出す」「出荷後に請求書を発行する」「月末に売上を締める」といった単位になります。

次に、それぞれの業務について、通常の流れに加えて、例外的な流れも洗い出します。受入テストで問題が見つかるのは、多くの場合この例外の流れです。

• 注文の内容を途中で変更する、キャンセルする
• 在庫が足りないときに一部だけ出荷する
• 締め日が休日にかかる
• 入力の途中で画面を閉じてしまい、やり直す
• 担当者が不在で、別の権限を持つ人が代わりに処理する
• 同じ顧客や商品が重複して登録されている

例外の流れは、現場の担当者が一番よく知っています。テストケースを作る段階で、実際に業務を回している人にヒアリングし、「普段どんなときに困るか」「年に数回しか起きないが必ず起きることは何か」を聞いておくと、重要なシナリオを漏らさずに済みます。業務フローの描き方は、用語解説の業務フロー図も参考にしてください。

テストケースの書き方

テストケースは、次の項目を表形式でまとめると管理しやすくなります。

「期待する結果」は、できるだけ具体的に書きます。「正しく表示される」ではなく、「一覧の金額欄に税込金額が表示され、合計が請求書と一致する」のように、誰がテストしても同じ判断ができる書き方にします。

テストデータの用意のしかた

テストケースが用意できても、それを試すためのデータがなければテストは進みません。テストデータは、業務の実態に近いものを用意することが重要です。たとえば、取引先名がとても長い、住所に旧字体や記号が含まれる、商品が数百点ある、一つの注文に多数の明細がある、といった実際の業務で起こりうる条件を含めておくと、画面の表示崩れや処理の遅さに気づけます。

一方で、本番の顧客情報をそのままテスト環境に入れるのは避けるべきです。氏名やメールアドレス、電話番号は架空のものに置き換えるか、加工したデータを使います。特にメールアドレスは、テスト中の自動送信で実在の顧客にメールが届いてしまう事故の原因になるため、社内で受信できるテスト用の宛先に置き換えておきます。

合否基準と検収の基準を決める

受入テストでよく揉めるのが、「どこまで直れば合格か」です。不具合がゼロになるまで検収しない、という考え方は現実的ではありません。そこで、不具合の重要度を分類し、重要度ごとに検収の条件を決めておくのが一般的です。

この分類と検収の条件は、テストを始める前に開発会社と文書で合意しておきます。テスト中に見つかった問題をどの重要度に分類するかでも意見が分かれることがあるため、迷ったときに誰が最終判断するかも決めておきます。

条件付きで検収する場合は、残っている不具合の一覧、それぞれの修正期限、修正後の確認方法を検収書や議事録に書き残しておきます。口頭の約束だけで検収すると、支払いが済んだ後に修正の優先度が下がり、いつまでも直らないという事態になりかねません。

もう一つ重要なのが、「仕様どおりだが使いにくい」という指摘の扱いです。これは不具合ではなく、仕様の変更にあたります。請負契約であれば、追加の費用や期間が必要になるのが一般的です。受入テストで出てきた改善要望は、別の一覧で管理し、検収の判断とは切り離して優先順位をつけましょう。変更の扱い方は開発途中の仕様変更にどう対応するかで詳しく説明しています。

受入テストの準備チェックリスト

テスト開始前に、次の項目を確認しておきましょう。

• 受入テストの期間と、参加者の業務時間を確保したか
• 業務シナリオごとのテストケースが作成され、開発会社とも共有したか
• 通常の流れだけでなく、例外の流れのケースが含まれているか
• 合否基準と不具合の重要度分類を開発会社と合意したか
• テストデータを用意し、本番の個人情報をそのまま使っていないか
• テスト環境のURL、アカウント、権限が参加者全員に配布されたか
• メール送信や外部サービス連携が、テスト用の宛先・設定になっているか
• 不具合の報告方法（画面の写真、操作手順、発生日時）を決めたか
• 不具合の一覧をどこで管理し、誰が開発会社とやり取りするかを決めたか
• 修正版の再テストの期間を、スケジュールに含めたか
• 性能（画面表示の速さ、同時に使う人数）を確認する必要があるか検討したか
• 権限ごとに見える画面・できる操作が正しいかを確認するケースがあるか

最後の二つは見落とされやすい項目です。少人数でのテストでは問題なくても、本番で多くの人が同時に使うと動きが遅くなることがあります。また、一般の担当者が管理者向けの画面を見られてしまう、といった権限の不備は、業務の流れに沿ったテストだけでは見つけにくいため、意識的にケースを作ります。

テスト実施と不具合報告のコツ

テストの実施中は、結果を必ずその場で記録します。後でまとめて書こうとすると、どの操作で何が起きたかを正確に思い出せなくなります。

不具合を報告するときは、次の情報をそろえると、開発会社が原因を早く特定できます。

• どの画面で、どのアカウント（権限）で操作したか
• どの順番で何を入力・クリックしたか
• 期待していた結果と、実際の結果
• 画面の写真や、表示されたエラーメッセージ
• 発生した日時と、毎回起きるのか、たまに起きるのか

報告の窓口は一本化します。複数の担当者がそれぞれ開発会社に連絡すると、同じ不具合が重複して報告されたり、修正の優先順位が分からなくなったりします。発注側の受入テスト責任者が一覧を取りまとめ、重要度をつけてから開発会社に渡す流れにしましょう。

修正版が届いたら、修正された箇所だけでなく、その周辺の機能も確認します。一つの修正が別の場所に影響することがあるためです。この「直したことで別の箇所が壊れていないか」を確かめる考え方は、回帰テストと呼ばれます。

架空の例：会員サイトの受入テスト

ここでは、架空の例で受入テストの進め方を見てみます。

ある教室運営の会社が、会員向けの予約・決済サイトを開発会社に依頼したとします。受入テストの責任者になった運営担当者は、まず会員の一年間の動きを書き出しました。入会する、体験レッスンを予約する、月謝の自動決済が行われる、振替予約をする、カードの有効期限が切れる、休会する、退会する、という流れです。

次に、教室のスタッフに「困ることが多い場面」を聞いたところ、「振替の期限ぎりぎりの予約」「家族で別々のコースに通う会員」「月の途中での休会」が挙がりました。これらを例外シナリオとしてテストケースに加え、全部で数十件のケースを用意しました。

テストでは、決済の失敗時に会員へ送られるメールの文面が、開発会社の想定していたものと教室の運用とでずれていることが分かりました。これは仕様書に文面が書かれていなかったことが原因で、改善要望として扱い、リリース前に文面だけ差し替えることで合意しました。一方、休会中の会員が予約画面から予約できてしまう不具合は「重大」に分類し、修正と再テストを終えてから検収しました。

この例のポイントは、運営スタッフの声から例外シナリオを拾い、不具合と改善要望を分けて扱ったことです。

よくある失敗と避け方

開発会社のテスト結果を見て受入テストを省略する

「開発会社がしっかりテストしたと言っているから」と、受入テストを簡単な動作確認だけで済ませるケースです。先に述べたとおり、開発会社のテストは設計書どおりかを確かめるもので、業務に合うかまでは保証しません。受入テストを省くと、業務とのずれが本番で初めて見つかります。

現場の担当者が参加しない

情報システムの担当者や管理職だけでテストを行い、実際に毎日使う担当者が参加しないケースです。普段の操作手順や例外処理を知っているのは現場の担当者です。全員でなくてよいので、各業務の代表者に参加してもらいましょう。

テスト期間が短すぎる

リリース日が迫っている中で、受入テストの期間が数日しか取れないケースです。不具合の修正と再テストの時間が足りず、問題を抱えたまま検収することになります。スケジュールを立てる段階で、受入テストと修正・再テストの期間を確保しておきます。開発全体の期間の考え方は、システム開発の期間はどう決まるかで説明しています。

不具合と改善要望を混ぜて扱う

テストで出た指摘をすべて「不具合」として扱い、全部直るまで検収しない、と主張してしまうケースです。開発会社との関係が悪くなるだけでなく、リリースが遅れて事業にも影響します。仕様どおりかどうかで、不具合と改善要望を分けて扱いましょう。

本番データの移行を確認しない

新しいシステムに既存のデータを移す場合、テストは架空のデータで行い、本番データの移行結果を確認しないまま稼働するケースです。移行したデータの件数や内容が正しいか、文字化けや欠落がないかも、受入テストの範囲に含めておきます。

よくある質問

Q. 受入テストのテストケースは開発会社に作ってもらえますか？

作成を手伝ってもらうことはできますが、どの業務シナリオを確かめるべきかを決めるのは発注側です。開発会社が作ったケースは、どうしても設計書の観点に寄ります。業務の観点からのシナリオは、発注側で用意することをおすすめします。

Q. 受入テストの期間はどれくらい見ておけばよいですか？

システムの規模や業務の数によって大きく異なります。目安を決めるときは、テストケースの数と一日に実施できる件数から逆算し、さらに不具合の修正と再テストの期間を加えて考えます。修正と再テストを一回以上見込んでおくのが安全です。

Q. 検収した後に不具合が見つかったらどうなりますか？

請負契約であれば、仕様との不一致について開発会社が修正などの責任を負う期間を定めているのが一般的です。準委任契約や保守契約の場合は、契約で定めた範囲で対応します。契約形態と責任の違いは請負契約と準委任契約の選び方で説明しています。

Q. 少人数の会社でも受入テストは必要ですか？

必要です。ただし、規模に合わせて簡略化してかまいません。主要な業務シナリオを十数件に絞り、実際に使う人が通しで操作してみるだけでも、多くの問題を事前に見つけられます。

Otsumuに相談できること

業務を知っている担当者が社内にいて、テストに参加する時間を確保できるなら、受入テストは自社で十分に進められます。本記事の手順とチェックリストに沿って、業務シナリオと合否基準を準備してみてください。

一方で、テストケースの作り方が分からない、業務シナリオの洗い出しに時間が割けない、開発会社との合否基準の調整に不安がある、といった場合は、発注側の立場で支援できる外部の力を借りると、検収の判断がしやすくなります。

Otsumuは、構想から開発・運用・改善まで一気通貫で支援する立場から、業務シナリオに沿った受入テストの設計や、開発会社との合否基準のすり合わせもお手伝いしています。開発の進め方全般はシステム開発、既存システムの保守や改修を含む場合は保守・運用のページもご覧ください。

まずは30分の無料相談で、現在の開発状況とお困りの点をお聞かせください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01