受入テストの進め方｜発注側が主役になるテストの目的・4ステップ・テストケースの書き方と合否基準ARTICLE

要件定義を経て、開発側が設計と実装を終えると、いよいよシステムが手元に届きます。ここで発注側は、第1回で整理した工程の主役に戻ります。それが受入テストです。

受入テストは、開発の成果物がビジネス要件を満たしていることを検証する、品質保証の最終段階です。ここを開発側の動作確認で済ませてしまうと、「仕様どおりに動くが、業務では使えない」システムを、そのまま受け取ることになります。

本記事はシリーズ「発注側のための要件定義」の第5回、最終回として、発注側が主役になる受入テストの進め方を解説します。

受入テストの位置づけ ―― 品質保証の最後の段階

システム開発では、段階を分けてテストを行います。受入テストは、その最後に位置します。

• ユニットテスト：個々の部品が、仕様どおりに動くことを確認します。開発側が行います。
• 結合テスト：複数の部品を組み合わせたときに、正しく連携して動くことを確認します。開発側が行います。
• システムテスト：完成したシステム全体が、仕様どおりに動くことを総合的に確認します。開発側が行います。
• 受入テスト：最終的な成果物が、ビジネス要件と関係者の期待を満たしているかを評価します。発注側が主役です。

受入テストの目的は、ビジネス要件を満たしていることの確認、リリース後のリスクの低減、そして最終的な品質の保証です。この段階を通じて、システムが実際の業務環境での使用に耐えうることを確かめます。

開発側の3つのテストと受入テストの違いは、何を基準に合否を決めるかです。開発側のテストは「仕様（要件定義書や設計書）どおりか」が基準です。受入テストは「業務として成り立つか」が基準です。仕様どおりに作られていても、実際の業務の流れに合わなければ、受入テストでは不合格になります。

どのテストが、上流のどの文書を基準にするかを表したのが、V字モデルと呼ばれる図です。

左側で上から順に「決めて、作った」文書が、右側の同じ高さにあるテストの合否基準になります。実装はユニットテストで、詳細設計書は結合テストで、基本設計書はシステムテストで確かめられ、いちばん上の要件定義書を確かめるのが受入テストです。第4回で「要件定義書に書かれていないことは、作られませんし、テストもされません」と書いたのは、このためです。受入テストで確かめられるのは、要件定義書に書いたことだけです。

受入テストの4ステップ

受入テストは、次の4つのステップで進めます。

1. テスト計画の作成

テストの全体的な進め方を決め、範囲、方法、日程を明確にします。どんなテストを行うか、誰が実施するか、テストに必要なもの（環境、データ、人の時間）は何かを、この段階で決めます。

発注側の実務で最も重要なのは、人の時間を確保することです。受入テストは、実際に業務を行う人が手を動かす必要があります。通常業務と並行して行うことになるので、いつ、誰が、どのくらいの時間をテストに使うのかを、上長を含めて合意しておきます。

2. テストケースの準備

具体的なテストケースを作り、それぞれが要件のどの項目を検証するのかをはっきりさせます。テストの手順と、期待する結果を文書にします。書き方は後述します。

3. テストの実施

用意したテストケースに従って、実際にテストを行います。システムが正しく動くか、要件を満たしているかを確かめ、結果を記録します。「動いた」「動かなかった」だけでなく、期待した結果とどう違ったかを残しておくと、次の評価がしやすくなります。

4. 結果の評価と報告

テストの結果を分析し、問題点や不具合を特定します。結果はテスト報告書として文書にし、開発側と関係者に報告します。問題があれば、修正して再テストを行います。

ここで発注側が判断すべきなのは、見つかった問題を「直してから受け入れる」のか「受け入れたうえで後から直す」のかです。すべてを直すまで受け入れないと、リリースがいつまでも延びます。業務に支障がある問題は直してから、軽微な問題は受け入れたうえで対応する、という線引きを、開発側と相談して決めます。

効果的な受入テストのための3つの戦略

受入テストを形だけで終わらせないために、K.S.Rogers が重視している戦略を3つ挙げます。

1. 早期からのテスト計画

プロジェクトの初期の段階からテスト計画を始めることで、テストの活動がプロジェクト全体の計画に組み込まれ、十分な時間と人が確保されます。

具体的には、要件定義が終わった直後に、テストの範囲・目的・日程を決めます。要件定義書が確定していれば、何をテストすれば要件を満たしたと言えるかは決められるからです。開発の終わり際に「そろそろ受入テストを」と始めると、人も時間も確保できず、形だけのテストになります。

2. 関係者の参加

関係者をテストの過程に積極的に関わらせることで、テストの目的と期待が明確になり、最終的な成果物が実際のビジネス要件を満たすかどうかを、効果的に評価できます。

「関係者」の中心は、実際にシステムを使う人です。要件を決めた担当者だけでなく、日々その業務を行っている現場の人にテストに入ってもらいます。担当者には見えなかった「実際の業務ではこうしている」が、ここで初めて表に出ます。定期的なミーティングでテスト計画を共有し、意見を集めます。

3. 反復的なテストと改善

テストを通じて得られた結果をもとに、テストを繰り返し行うことで、成果物の品質を段階的に高めていきます。

各サイクルの後に結果を評価し、問題点を特定して改善策を実施します。必要に応じてテストケースを調整し、再テストを行います。受入テストは一回で終わるものではなく、直しては確かめる、を繰り返す工程だと考えておくと、計画の段階で適切な期間を取れます。

テストケースの書き方 ―― 要件からたどる

テストケースは、要件定義書の項目ごとに作ります。基本の構成は、番号、対応する要件、前提、手順、期待する結果、合否の6つです。

書くときのポイントは4つです。

• 要件定義書からたどる：テストケースは、要件定義書の項目と一対一で対応させます。対応する要件のないテストケースは、何を確かめているのか分かりません。逆に、テストケースのない要件は、確かめられずにリリースされます。
• 期待する結果を、要件の条件そのままに書く：「正しく動く」ではなく、「報告が保存され、上長に通知が届く。所要10分以内」のように書きます。第4回で非機能要件を数字で書くよう勧めたのは、ここで合否を判定するためです。
• 正常系と異常系の両方を用意する：正しい操作で正しく動くか（正常系）だけでなく、入力を間違えたとき、途中でやめたとき、権限のない人が操作したときにどうなるか（異常系）も確かめます。業務の現場では、間違った操作は必ず起きます。
• 実際の業務に近いデータで試す：「テスト用」の整ったデータではなく、実際の業務で扱うデータに近いもので試します。例外的な取引や、古い形式のデータで問題が出ることは珍しくありません。

合否の基準は、要件定義書にある

受入テストで最も揉めやすいのが、「これは合格なのか、不合格なのか」です。

基準は、要件定義書です。第3回で言葉にした要求が、第4回で要件になり、その要件がテストケースになる。この一本のつながりがあれば、「要件定義書に書いた条件を満たしているか」で合否が決まり、感覚や好みで揉めることがなくなります。

逆に言えば、要件定義書に書かれていないことは、受入テストの不合格の理由にはできません。「当然こう動くと思っていた」は、要件定義書に書いていなければ、開発側にとっては新しい要求です。それは不具合ではなく、変更要求として扱い、第4回で決めた変更管理の手続きに乗せます。

このルールは、発注側にとって厳しく感じられるかもしれません。しかし、要件定義の段階で「書いていないものは作られない」と分かっていれば、要件定義に真剣に取り組む理由になります。受入テストの厳しさは、要件定義の質を上げる力になります。

受入テストでよくあるつまずき

1. 開発側の動作確認を、受入テストの代わりにする

「開発会社がテスト済みなので大丈夫」と、発注側のテストを省略するケースです。開発側のテストは「仕様どおりか」の確認であり、「業務で使えるか」は確かめられていません。リリース後に現場から「使えない」の声が上がって初めて気づきます。

2. 担当者だけでテストし、現場の人が触らない

要件を決めた担当者が一人でテストし、実際に使う現場の人が本番まで触らないケースです。担当者は「要件どおり動くか」を見てしまい、「日々の業務の流れに合うか」までは見えません。現場の人がテストに入ると、担当者が想定していなかった使い方が必ず出てきます。

3. 合否の基準がなく、「なんとなく」で判断する

テストケースに期待する結果が書かれておらず、触ってみた感触で合否を決めるケースです。人によって判断が変わり、不合格の理由を開発側に説明できません。要件定義書の条件を、そのままテストケースの期待する結果にしておきます。

支援の現場で見た、テストを「業務の視点」で行う効果

音声ライブ配信アプリの開発体制を整えた事例では、リリースして終わりではなく、リリース後も継続的に改善できる状態を作ることを重視しました。受入テストで確かめ、直し、また確かめる、という反復の型は、リリース後の改善にもそのまま使えます。

K.S.Rogers の要件定義支援では、要件定義書を作る段階から「これはどうテストするか」を意識して項目を書きます。テストできない要件は、曖昧な要件だからです。

参考になる公的資料

• IPA「ユーザのための要件定義ガイド 第2版」：要件定義の成果物が後の工程でどう使われるかを含め、発注側の視点で整理されています
• IPA「情報システム・モデル取引・契約書（第二版）」：検収（受入）の位置づけと、ユーザ企業・ITベンダの責任分担が契約の観点で整理されています

受入テストの設計からご一緒します ―― K.S.Rogers の要件定義支援

K.S.Rogers では「決まっていないところから一緒に考える」をコンセプトに、要件定義支援サービスを提供しています。要件定義書の作成から、テスト計画とテストケースの設計、受入の判断まで、発注側の立場で伴走します。

まとめ

• 受入テストは品質保証の最後の段階で、業務で使えるかを発注側が確かめる工程です。開発側の動作確認では代わりになりません
• 進め方は、テスト計画 → テストケースの準備 → 実施 → 評価と報告の4ステップです。計画は要件定義の直後に始め、実際に使う人に参加してもらい、直しては確かめるを繰り返します
• テストケースは要件定義書の項目からたどって作り、期待する結果は要件の条件をそのまま書きます。正常系と異常系、実際に近いデータで試します
• 合否の基準は要件定義書です。書かれていないことは不具合ではなく変更要求として扱います。この厳しさが、要件定義の質を上げる力になります

シリーズを終えて

本シリーズでは、発注側と開発側の役割分担から始め、企画書の作り方、要求定義、要件定義書、そして受入テストまで、発注側が主役になる工程を順に見てきました。

一貫して伝えたかったのは、システム開発の成否は、発注側が「何のために、何を求めているか」をどれだけ言葉にできるかで決まるということです。技術は開発側に任せられますが、目的と要求は発注側にしか決められません。

要件定義の進め方の全体像は要件定義の進め方にまとめています。自社のプロジェクトについて相談したい方は、お問い合わせからお気軽にご連絡ください。