システム開発のテスト工程とは？種類・流れとV字モデル・発注者が見る判断軸

システム開発のテスト工程は、単体テスト・結合テスト・システムテスト・受入テストの4段階で組み立てるのが基本です。各テストはV字モデルで設計工程と一対一に対応し、どの設計の妥当性を確かめるのかがあらかじめ決まっています。本記事で扱うのは、4種類のテストの目的と担当、テスト計画から不具合管理までの進め方、そして発注者が見るべき役割分担・失敗パターン・自動化の採否です。テストの技術的な配分設計は既存の解説記事に委ね、本記事は「発注したシステムの品質をどう担保するか」の判断軸に絞りました。

まとめ｜テスト工程の全体像と発注者が押さえる判断軸

テスト工程の骨格は、V字モデルの右側にある4段階です。詳細設計に対応する単体テスト、基本設計に対応する結合テスト、要件定義に対応するシステムテスト、そして発注者が業務目線で確かめる受入テスト。この対応関係を理解しておけば、テスト仕様書が「どの設計を検証しているか」を発注側でも読み解けます。

発注者が品質を左右するのは、テストの技術ではなく体制と検収の設計です。誰が単体テストの証跡を残すのか、受入テストのシナリオを誰が書くのか、不具合の再発をどのテストで止めるのか。ここを契約前に決めておくと、リリース直前の手戻りが減ります。テストの種類を暗記するより、役割分担と合否基準を先に固めることが、システム開発の品質を守る近道です。

システム開発におけるテスト工程の位置づけとV字モデルの対応関係

テスト工程は、プログラミングが終わってから始まる「後工程」ではありません。何をテストするかは設計段階で決まっているため、テストは設計の裏返しとして進みます。この対応を図式化したのがV字モデルです。システム開発の工程とは？7フェーズの成果物と工数比率を発注者目線で解説した記事で全体像を押さえたうえで読むと、テストの位置づけがつかみやすくなります。

V字モデルが示す設計工程と各テスト工程の一対一の対応関係と確認観点

V字モデルは、左側の設計工程を下りて実装で折り返し、右側のテスト工程を上っていく形で描きます。左右で同じ高さの工程が対応し、その設計で決めた内容をそのままテストで検証します。

この対応が崩れると、テスト仕様書に「どの設計に対する検証か」を書けなくなります。発注者がテスト計画を確認するときは、まず各テストがどの設計工程と紐づくかを見ると、抜け漏れの兆候を早く察知できます。

テスト工程が品質と開発の総コストを左右する構造的な理由と仕組み

不具合の修正コストは、発見が遅れるほど跳ね上がります。設計段階での発見なら設計書の直しで済みますが、受入テストやリリース後の露見となれば、影響範囲の調査・改修・再テストへと連鎖します。後工程で見つかった不具合の修正費用は前工程の数倍から数十倍に膨らむとされ、その連鎖を前工程で断つのがテストを段階化する狙いです。

だからこそ単体テストを省いて結合テストへ飛ばす判断は、短期的に工数を削れても総コストを押し上げがちです。テスト工程は品質保証の作業であると同時に、手戻りを前工程で食い止めるコスト管理の仕組みでもあります。

単体・結合・システム・受入の4種類とテスト工程ごとの目的と担当

テストの4段階は、検証する範囲が「部品→つながり→全体→業務」と段階的に広がります。範囲が広がるほど担当は開発者からユーザーへ移り、確かめる観点も技術から業務へと変わっていきます。順に見ていきましょう。

単体テスト：モジュール単体の動作を実装した開発者が確認する工程

単体テスト（ユニットテスト）は、関数やクラスといった最小単位が仕様どおりに動くかを、実装した開発者自身が確かめる工程です。境界値・異常値・分岐網羅など、コードの内部構造を踏まえた検証が中心になります。ここで担保する品質が、後続の結合・システムテストの土台になります。

単体テストと結合テストの線引きは、現場や書籍で揺れがあります。テストの粒度をチーム全体で揃える考え方は、単体テストと結合テストはもう古い！Google流テストサイズとは？を解説した記事で扱う「テストサイズ」の観点が参考になります。

結合テスト：モジュール間の連携とインターフェースを検証する工程

結合テスト（インテグレーションテスト）は、単体で確認済みのモジュールを組み合わせ、データの受け渡しや呼び出し順序が設計どおりかを確かめます。片方がAPIの戻り値を誤解している、文字コードや日付形式がずれている、といった連携の食い違いが表面化するのもこの段階です。外部システムやデータベースとの接続確認も、多くはここに含めます。

システムテスト：システム全体の機能と非機能の品質を確かめる工程

システムテスト（総合テスト）は、本番に近い構成でシステム全体を通し、機能要件と非機能要件の両方を検証します。機能面では業務シナリオに沿った一連の流れを確認し、非機能面では性能（レスポンス・同時接続）、セキュリティ、障害時の挙動などを測ります。負荷試験で目標の同時アクセス数をさばけるか、といった検証がこの工程の代表例です。

受入テスト：発注者が実業務の目線で合否を最終判断する検収工程

受入テスト（UAT／検収テスト）は、発注者やエンドユーザーが主体となり、実際の業務が回るかを自分たちの手で確かめる工程です。開発チームが想定しづらい現場の運用パターンや例外処理は、業務を知るユーザーだからこそ洗い出せます。ここでの合格がリリースと検収の判断材料になるため、合否基準を発注時に文書化しておくと、受け渡しの認識ずれを防げます。

テスト計画・設計から不具合管理と再テストまで進める実務全体の手順

各テストは「いきなり実施」では回りません。計画で範囲と合否基準を決め、設計でケースを起こし、実施して結果を記録し、見つかった不具合を管理して再テストへ戻す。この循環がテスト工程の実務です。

テスト計画とテスト設計で先に決める検証範囲・観点・合否の基準

テスト計画では、対象範囲・スケジュール・体制・環境・合否基準を定めます。続くテスト設計で、要件と設計書からテストケースを起こし、期待結果を文書として明文化します。この段階で「何をもって合格とするか」を数値や条件で固めておけば、実施フェーズでの判断の揺れは小さくなるでしょう。テストケースの網羅度をどう測るかは、コードのどこを通したかを見るカバレッジの考え方が土台になります。

不具合管理と再テスト・回帰テストで品質を安定させる実務の進め方

実施で見つかった不具合は、再現手順・優先度・影響範囲を添えて記録し、修正後に同じケースで再テストします。ここで見落とされがちなのが、修正が別の箇所を壊していないかの確認です。既存機能への影響を確かめるリグレッションテスト（回帰テスト）の目的・範囲選定・自動化の判断を解説した記事のように、修正のたびに回帰確認を組み込むと、直したはずの機能が別の変更で再び壊れる事態を防げます。

1. テスト計画：範囲・合否基準・体制・環境を決める
2. テスト設計：要件・設計書からテストケースを作成する
3. テスト実施：ケースを実行し結果を証跡として残す
4. 不具合管理：再現手順・優先度を記録し修正へ回す
5. 再テスト・回帰テスト：修正確認と既存機能への影響確認

この循環を各テスト工程で回すことで、単体から受入まで品質を積み上げていきます。

発注者の目線でテスト工程の品質と体制・検収を見極めるための判断軸

ここからが、テストの技術解説には載りにくい実務の勘所です。発注側がテスト工程で品質を守れるかは、テストの巧拙よりも「誰が何をどこまでやるか」と「合格をどう定義するか」で決まります。受託開発の現場で手戻りが起きる場面から、判断軸を言い切ります。

ベンダーと自社の役割分担で発注前に決めておくべき責任の境界線

単体・結合・システムテストはベンダーが担い、受入テストは発注者が担う。この分担が基本形ですが、曖昧なまま進めると「どちらもやっていない領域」が生まれます。契約前に決めるべきは次の3点です。

• 単体・結合テストの証跡（テスト結果報告書）をどこまで納品物に含めるか
• 受入テストのシナリオとテストデータを誰が用意するか
• 不具合の切り分け（仕様か障害か）を判断する責任者は誰か

とくに受入テストは発注者の責任範囲でありながら、シナリオ作成をベンダー任せにしがちです。業務を最も理解しているのは発注側なので、シナリオの骨子は自社で用意し、テスト実施を支援してもらう形が現実的です。

テスト工程で発注側が陥りやすい失敗の典型パターンと回避の判断

手戻りの多いプロジェクトには共通の型があります。まず、テスト期間をスケジュールの調整弁にしてしまう失敗。開発が遅れた分をテスト期間の圧縮で吸収すると、単体テストが形骸化し、後工程に不具合が流出します。テスト工程は削る前提の余白ではありません。

次に、合否基準を「動けばよし」で済ませる失敗。数値化された基準がないと検収でもめます。性能なら目標レスポンス、機能なら網羅すべき業務シナリオ、というように合格条件を発注時に決めておくべきです。曖昧な検収は、リリース後のトラブル対応コストとして跳ね返ります。

品質を担保しながら開発から運用までを一貫して任せたい場合は、テスト体制と回帰テストの仕組みごと委ねる選択肢もあります。一創の保守運用・内製化支援サービスでは、開発後の品質維持や改修時の回帰テストまで含めた体制づくりを支援しています。テスト工程の内製化に不安があるなら、どこまで自社で持つかを相談したうえで分担を決めるのが安全です。

テスト自動化とアジャイルを採用すべき条件と過剰投資になる場面

自動化は万能ではありません。仕様変更が頻繁な立ち上げ期にUI操作の自動テストを作り込むと、画面が変わるたびにテストが壊れ、保守負担が開発を上回ります。自動化が効くのは、仕様が安定し、同じ確認を何度も繰り返す回帰テストの領域です。逆に、一度きりの探索的な確認や、要件が固まっていない初期フェーズでは、手動テストのほうが速く安く済みます。

どのテストを自動化し、どの層を厚くするかは、テストピラミッドで単体・結合・E2Eの配分を設計する考え方を解説した記事が指針になります。画面全体を通すE2Eテストの目的とツール選定・導入判断を解説した記事も、自動化の対象を絞る判断に役立ちます。結論として、自動化は「変更頻度が低く、繰り返し回数が多い」テストから導入し、変化の激しい層は手動で持つ。この線引きを外すと、自動化がコスト削減ではなく負債になります。

システム開発のテスト工程について発注者からよくある質問と回答例

発注者や開発の担当者から寄せられることの多い質問に、実務の観点でお答えします。

単体テストと結合テストの違いは何ですか？

単体テストは関数やクラスといった最小単位が単体で正しく動くかを確かめる工程で、実装した開発者が担当します。結合テストは単体で確認済みのモジュールを組み合わせ、モジュール間のデータ連携や呼び出しが設計どおりかを検証します。検証する範囲が「部品単体」か「部品同士のつながり」かが、両者を分ける基準です。

システムテストと受入テストはどう違いますか？

システムテストは開発側のテストチームが、本番に近い構成で機能・性能・セキュリティなどシステム全体の品質を確かめる工程です。受入テストは発注者やユーザーが主体となり、実際の業務が回るかを業務目線で判断します。担当が開発側かユーザー側か、確かめる観点が技術か業務適合か、という点で役割が分かれます。

テスト工程はどのくらいの期間・工数を見込むべきですか？

プロジェクトの規模や品質要求で変わりますが、単体から受入までのテスト工程は開発全体の3割前後を占めることが多く、業務システムでは設計と同等の比重を置くこともあります。スケジュール遅延の吸収先にテスト期間を充てると品質が崩れるため、計画時にテスト工数を独立した枠として確保しておくのが安全です。

アジャイル開発ではテスト工程はどう変わりますか？

アジャイルでは、V字モデルのようにテストを最後にまとめて実施せず、イテレーションごとに設計・実装・テストを繰り返します。単体テストや回帰テストを自動化して各スプリントで継続的に回す進め方が一般的です。テストの種類そのものは変わりませんが、実施のタイミングが工程の最後から開発サイクルの中へ分散します。

発注時にテスト工程で確認しておくべきことは何ですか？

単体・結合テストの結果報告書が納品物に含まれるか、受入テストのシナリオとデータを誰が用意するか、不具合の合否基準が数値や条件で定義されているか、の3点をまず確認してください。この3点を契約前に文書化しておくと、検収時の認識ずれとリリース後の手戻りを大きく減らせます。

関連記事

• システム開発の工程とは？7フェーズの成果物と工数比率を発注者目線で解説：テスト工程を含む開発全体の流れと各工程の成果物を確認できます。
• 単体テストと結合テストはもう古い！Google流テストサイズとは？：単体・結合の粒度の揺れを、テストサイズという別の切り口で整理します。
• テストピラミッドとは？単体・結合・E2Eの配分と実装者向けテスト戦略設計：どのテストを厚くするか、自動化の配分設計を深掘りします。
• リグレッションテスト（回帰テスト）とは？目的・範囲選定・自動化と実施判断を解説：修正時の再発防止をどう仕組み化するかを解説します。
• E2Eテストとは？目的・他テストとの違い・ツール選定と導入判断まで解説：画面全体を通す自動テストの導入可否を判断できます。