ソフトウェアテストの種類と工程を整理｜単体・結合・システム・受け入れの違いと使い分け

発注者が知っておくべきソフトウェアテストの全体像

テストはなぜ必要か——品質問題が起きる構造的な理由

業務システムやWebアプリの開発において、リリース後に不具合が発覚するケースは少なくありません。その原因の多くは、開発技術そのものではなく、テスト工程における認識のズレにあります。「テストはベンダーに任せておけばよい」という前提で進めた結果、検証の範囲や基準が発注者の期待と合わず、本番環境で初めて問題が顕在化するという構図です。

ソフトウェアテストとは、システムが設計どおりに動作するかを体系的に確認するプロセスです。その目的は不具合の発見にとどまらず、リリース判断の根拠となる品質の可視化にあります。テストを適切に設計・実施することで、手戻りコストの削減や、ユーザーへの影響を最小化することができます。

発注者がテストを「開発側の作業」として捉えている場合、次のような問題が起きやすくなります。

• テスト範囲が暗黙の了解のまま進み、重要な業務フローが検証されていない
• 受け入れテストの時間が圧迫され、形式的な確認で終わってしまう
• テスト報告書を受け取っても、内容の妥当性を判断できない

こうしたトラブルを防ぐには、発注者自身がテスト工程の種類と目的を理解し、ベンダーと対等に議論できる状態をつくることが重要です。

本記事で整理する範囲と読み方

本記事では、ソフトウェアテストの種類と各工程の違いを、発注側の意思決定者が判断に活かせる粒度で解説します。具体的には、単体テスト・結合テスト・システムテスト・受け入れテストという4つの主要工程の目的と役割の違い、テスト観点の設計方法、仕様書・報告書の読み方、そして自動化を含む効率化の選択肢まで、開発委託時に必要な論点を網羅的に扱います。

技術者向けの実装詳細には踏み込まず、「どの工程で何を確認すべきか」「ベンダーに何を問うべきか」という観点を軸に整理しています。テスト工程全体の構造を把握したい方は、次のセクションから順を追って読み進めることで、体系的な理解が得られます。

ソフトウェアテストの7原則——品質判断の前提となる考え方

ソフトウェアテストには、国際的な資格団体であるISTQB（International Software Testing Qualifications Board）が定めた「7原則」があります。技術者の間では広く知られていますが、発注側の意思決定者にとっても、品質判断の前提として押さえておく価値があります。

7原則の一覧と発注者にとっての意味

• テストはバグの存在を示すが、不在は証明しない：テストをどれだけ実施しても「バグがゼロ」とは言い切れません。「テストが完了した＝安全」ではなく、「どこまでの範囲を確認したか」で品質を判断する視点が必要です。
• 全数テストは不可能：すべての入力パターンや操作経路を網羅することは現実的ではありません。発注時には「何を優先してテストするか」をベンダーと合意することが重要です。
• 早期テストで費用を抑えられる：バグの発見が遅れるほど、修正コストは増大します。要件定義や設計の段階からテスト観点を取り入れることで、手戻りを抑えられます。
• バグの偏在：不具合は特定のモジュールや機能に集中しやすい傾向があります。リスクの高い箇所を重点的に確認する方針が合理的です。
• 殺虫剤のパラドックス：同じテストを繰り返しても、新たなバグは見つかりにくくなります。テストケースは定期的に見直す必要があります。
• テストはコンテキストに依存する：ECサイトと医療システムでは求められる品質水準が異なります。テストの深度は用途やリスクに応じて設計されるべきです。
• 「バグゼロ」の誤解：検出されたバグをすべて修正しても、それが使いやすい・要件を満たすとは限りません。品質はバグ数だけで測れません。

原則から導かれる発注時のチェックポイント

7原則を踏まえると、発注者がベンダーに確認すべき論点が見えてきます。「テスト範囲はどう決めたか」「優先度の根拠は何か」「早期にテスト設計へ着手しているか」——これらを確認することで、テスト工程の妥当性を発注者側から評価できるようになります。テスト報告書の数字だけを見るのではなく、設計の考え方を問う姿勢が品質管理の精度を高めます。

テスト工程の全体構造——上流から下流への流れを把握する

ソフトウェア開発のテスト工程は、行き当たりばったりに実施するものではありません。開発の各フェーズと対応する形で、体系的に設計されています。この対応関係を視覚的に整理したフレームワークが「V字モデル」です。

V字モデルで見るテストと開発の対応関係

V字モデルでは、左下に向かって進む開発工程と、右上に向かって進むテスト工程が、アルファベットの「V」の字を描くように対応しています。具体的な対応関係は以下のとおりです。

• 要件定義 → 受け入れテスト（UAT）
• 基本設計 → システムテスト
• 詳細設計 → 結合テスト
• 実装（コーディング） → 単体テスト

この構造が示す本質は、「各テストは対応する開発フェーズの成果物を検証するために存在する」という点です。たとえば受け入れテストは、要件定義で合意した仕様通りにシステムが動くかどうかを確認する場です。単体テストは、詳細設計に基づいて実装されたコードの動作を最小単位で確認します。

上流テスト・下流テストという区分の意味

「上流」「下流」という表現は、V字モデルのどの位置を指すかによって意味が変わります。開発工程においては、要件定義・基本設計が「上流」、実装が「下流」です。一方、テスト工程では、実装直後に行う単体テストが「下流テスト」、最終段階に近い受け入れテストやシステムテストが「上流テスト」に相当します。

発注者として特に意識したいのは、上流テストほど「要件との整合性」を問う性格が強く、発注側の関与が大きくなる点です。下流テストは主にベンダー側の技術者が担い、発注者が直接確認する機会は少ない傾向があります。

テストフェーズ一覧——工程名と実施タイミングの対応表

テスト工程の種類と実施タイミングを整理すると、次のようになります。

• 単体テスト：実装完了直後。個々のモジュール・関数レベルで動作を確認する
• 結合テスト：単体テスト完了後。複数のモジュールを組み合わせて連携を検証する
• システムテスト：結合テスト完了後。システム全体を本番に近い環境で総合的に検証する
• 受け入れテスト（UAT：User Acceptance Testing）：システムテスト完了後。発注者がビジネス要件への適合を最終確認する

この順序は原則として変えられません。下流から順に品質を積み上げていく構造になっており、前のフェーズで残った欠陥は後のフェーズで発見するほど修正コストが高くなります。テスト工程の全体像を把握することは、ベンダーへの進捗確認や品質管理の会話を的確に行うための前提となります。

単体テスト（ユニットテスト）——最小単位での動作確認

単体テストが確認する範囲と観点

単体テスト（ユニットテスト）は、ソフトウェアを構成する最小単位——関数やメソッド、モジュールといった部品——が、それぞれ設計通りに動作するかを検証するフェーズです。結合テストやシステムテストへ進む前に、個々の部品の品質を担保しておく工程として位置づけられます。

確認する主な観点は以下の通りです。

• 正常系の動作確認：想定された入力に対して、期待する出力が返るか
• 異常系・境界値の検証：空欄・ゼロ・最大値など、イレギュラーな入力を受け取ったときに適切に処理されるか
• 条件分岐の網羅：if文やswitch文など、分岐ロジックがすべて正しく機能するか

実施するのは主に開発者自身です。コードを書いた担当者がテストコードも作成し、自動実行するケースが一般的です。この工程で見落としがあると、後の結合テストやシステムテストで原因特定が困難になるため、品質の入口として重要な役割を担っています。

発注者が確認すべき単体テストのアウトプット

発注側がコードを直接確認する必要はありませんが、単体テストに関するアウトプットとして、少なくとも以下の2点をベンダーに求めることが適切です。

• テスト仕様書（テスト設計書）：何をどの観点で検証するかが整理されたドキュメント。テスト項目数や観点の網羅性を確認できます
• テスト結果報告書：実施した項目数・合否・不具合件数と対応状況が記載されたドキュメント。消化率が100%に達しているか、未解決の不具合が残っていないかを確認します

「テストしました」という口頭報告だけで次工程に進む体制は、品質リスクを見えにくくします。ドキュメントを証跡として残す運用になっているかどうかを、契約や仕様確認の段階で取り決めておくことが重要です。

結合テスト（インテグレーションテスト）——モジュール間の連携を検証する

結合テストが必要な理由——単体テストとの違い

単体テスト（ユニットテスト）では、個々のモジュールが仕様どおりに動くかを確認します。しかし、個々のモジュールが正常に動作しても、複数のモジュールを組み合わせた際に問題が発生するケースは少なくありません。

たとえば、注文管理モジュールと在庫管理モジュールをそれぞれ単体でテストしたところ問題がなかったにもかかわらず、連携させると在庫の引き当て処理が二重に走ってしまうといった不具合が起きることがあります。このような「モジュール間のつなぎ目」に潜む問題を検出するのが、結合テスト（インテグレーションテスト）の目的です。

テスト工程の種類としては、単体テスト・結合テスト・システムテスト・受け入れテストの順に進むのが一般的です。結合テストは、単体での動作確認を終えたモジュール同士を組み合わせる段階で実施します。

内部結合テストと外部結合テストの区分

結合テストは、検証する範囲によって大きく2種類に分かれます。

• 内部結合テスト：開発対象システムの内部にある複数のモジュール・コンポーネント間のデータ受け渡しや呼び出し関係を検証します。同一システム内の機能連携が対象となります。
• 外部結合テスト：開発対象システムと、外部システム・外部サービスとの接続を検証します。たとえば、基幹システムとの連携API、決済サービスとのデータ連携、認証基盤との接続などが典型的な対象です。

特に外部結合テストは、外部サービス側の仕様変更や接続環境の制約により、テスト実施のタイミングや方法が制限されるケースがあります。発注者としては、外部システムとの結合テストをどの時点で実施するか、テスト用の環境（サンドボックスや検証環境）が用意されているかをベンダーに確認しておくことが重要です。

結合テストで見るべき主な観点

結合テストでは、以下のような観点を中心に検証が行われます。

• データの受け渡し：モジュール間でやり取りされるデータが、型・桁数・文字コードなどの形式を含めて正しく伝達されているか
• 処理の順序・タイミング：複数の処理が正しい順序で実行されているか、非同期処理の場合にタイミングのずれが生じていないか
• エラー時の挙動：一方のモジュールで異常が発生した場合に、他のモジュールへの影響が適切に制御されているか
• インターフェース仕様の整合性：API仕様書や設計書の定義と、実際の動作が一致しているか

ベンダーへの確認事項としては、「結合テストの完了基準（どの状態をもって合格とするか）」「不具合発生時の記録・報告の方法」「テスト結果のエビデンス提出の有無」などを事前に合意しておくことが、品質管理の観点から有効です。

システムテスト——本番環境に近い条件での総合検証

システムテストは、単体テストや結合テストを経たシステム全体を対象に、本番環境に近い条件で総合的な品質を検証する工程です。ソフトウェアテストの観点では、ここが「機能要件」と「非機能要件」の両方を同時に確認できる、最初の本格的な検証の場となります。

機能テストと非機能テスト——システムテストで確認する2つの軸

システムテストで確認する内容は、大きく2つに分かれます。

• 機能テスト：要件定義や設計書に定められた機能が、仕様どおりに動作するかを確認します。例えば「注文確定ボタンを押したときに在庫が正しく引き落とされるか」といった業務フロー全体を通じた検証がこれに当たります。
• 非機能テスト：性能（レスポンスタイム・スループット）、負荷耐性（同時接続数の上限）、セキュリティ（不正アクセスへの耐性）、可用性（障害発生時の復旧速度）など、機能以外の品質特性を検証します。

単体テストや結合テストでは非機能要件の検証はほぼ行われません。そのため、システムテストがソフトウェアテストの中で非機能要件を検証できる実質的に最初の機会となります。

合格基準（テスト終了条件）を事前に定める意味

発注者にとって特に重要なのが、システムテストの「合格基準」を要件定義の段階で決めておくことです。例えば「ピーク時に500件の同時アクセスがあっても、画面の応答が3秒以内であること」のように、数値で測定できる基準を設定しておく必要があります。

合格基準が曖昧なままだと、テスト終了のタイミングをベンダー側の判断に委ねることになり、品質の担保が難しくなります。単体テスト・結合テスト・システムテストの違いを踏まえた上で、システムテストの段階では発注者が検証観点と合格条件の設定に関与することが、納品後のトラブルを防ぐ有効な手段となります。

受け入れテスト（UAT）——発注者自身が主役となる最終確認

受け入れテスト（UAT：User Acceptance Testing）は、システムテストを経て納品前の最終段階に行うテストです。ここで主役を担うのは開発ベンダーではなく、発注者側です。「業務要件を満たしているか」「現場で実際に使えるか」という観点から、発注者が責任を持って検証します。

UATはベンダー任せにできない——発注者の役割と準備

単体テストや結合テスト、システムテストは、主にベンダー側が設計・実施します。一方、UATは発注者が主体となるテストです。ベンダーは技術的な品質を担保できますが、「業務フローに沿って使いやすいか」「現場の実態に合っているか」という判断は、業務を熟知している発注側にしかできません。

UATに必要な準備として、以下が挙げられます。

• テストに参加する現場担当者の選定と日程調整
• 本番に近いテスト用データの用意
• 業務シナリオに基づくテストケースの作成
• 不具合発見時の報告フローと対応ルールの整備

現場担当者の関与が薄いまま情報システム部門だけで進めると、実際の操作性や業務との整合性を見落とすリスクがあります。エンドユーザーとなる現場スタッフを早期から巻き込むことが重要です。

受け入れテストのシナリオ作成で意識すべき観点

UATのシナリオは、「システムの機能」ではなく「業務の流れ」を起点に設計します。たとえば「受注情報を登録し、在庫を確認して出荷指示を出す」という一連の業務フローを、実際の画面操作を通じてトレースするかたちで作成します。

テストシナリオで意識すべき主な観点は以下の通りです。

• 正常系の確認：通常業務の流れが期待通りに完結するか
• 異常系・例外処理の確認：入力ミスや想定外の操作時に適切なエラーメッセージが表示されるか
• 権限・アクセス制御の確認：担当者ごとに参照・編集できる範囲が正しく制限されているか
• データ連携の確認：他システムや帳票との連携が業務上問題のない精度で動作しているか

テストシナリオは、要件定義書や業務フロー図を参照しながら作成します。要件定義の段階で合意した内容が、実際の画面・動作として実現されているかを突き合わせる作業がUATの核心です。

合格・不合格の判断基準をどう設定するか

UATの合格・不合格の判断は、事前に明文化しておく必要があります。「なんとなく使えそう」という印象論で判断すると、納品後にトラブルが発生した際の責任の所在があいまいになるためです。

一般的な合格基準の設定例としては、以下のような項目が参考になります。

• 必須機能のテストケースをすべて実施し、重大な不具合（業務が停止するレベル）がゼロであること
• 軽微な不具合については件数や対応計画を合意のうえで受け入れ可とすること
• 現場担当者が代表シナリオを一通り操作できること

合格・不合格の判断基準は、テスト開始前にベンダーと合意しておくことが欠かせません。後から基準を変更すると、スケジュールや費用の調整が難航するケースが少なくないため、要件定義や契約段階で盛り込んでおくことが望ましいです。

4工程の違いを一表で整理——目的・実施者・観点・アウトプットの比較

単体・結合・システム・受け入れの4工程は、それぞれ目的も実施者も異なります。テキストで個別に説明を読んでも違いが混同されやすいため、以下の比較表で4軸をまとめて確認してください。

発注者にとって特に重要なのは、実施者の違いです。単体・結合・システムテストはベンダー側が主導しますが、受け入れテストは発注者自身が主体となります。ベンダーから「UAT対応をお願いします」と依頼された際に、何を準備すべきかを事前に把握しておくと、スケジュール調整や品質判断がスムーズになります。

テスト観点と観点表——何を確認するかを設計する考え方

テスト観点とは何か——設計の基本的な考え方

テスト観点とは、「何を、どのような条件で確認するか」という視点のことです。たとえば「正常な入力値で処理が完了するか」「上限値を超えた入力でエラーが返るか」「権限のないユーザーがアクセスできないか」といった確認の切り口が、それぞれひとつの観点にあたります。

観点の設計が不十分だと、テストケースの数が多くても抜け漏れが生じます。逆に観点が体系的に整理されていれば、テストの網羅性を担保しやすくなります。ソフトウェアテストの設計において、観点の洗い出しは品質の出発点となる作業です。

観点は大きく以下の軸で整理されることが多いです。

• 機能観点：仕様どおりに動作するか
• 入力値観点：正常値・異常値・境界値への対応
• 非機能観点：性能・セキュリティ・操作性など
• 業務フロー観点：実際の利用シナリオを通じた整合性

観点表の構成例と発注者が確認すべき箇所

観点表とは、テスト観点を一覧化したドキュメントです。テスト設計の段階でベンダーが作成し、テストケースの前段として共有されることが多いです。

一般的な観点表には、「対象機能」「確認する観点」「テスト条件の概要」「対応するテストケースの番号」といった列が並びます。発注者がこのドキュメントを受け取った際は、以下の点を中心に確認することをお勧めします。

• 業務要件との対応が取れているか：要件定義で合意した機能や条件が観点として拾われているかを照合する
• 異常系・境界値の観点が含まれているか：正常系だけでなく、エラー時の挙動やエッジケースへの言及があるかを確認する
• 非機能要件が対象外になっていないか：性能やセキュリティに関する観点が明示されているかを見る

観点表の粒度や網羅性は、ベンダーの品質管理の成熟度を測る手がかりにもなります。テスト設計の段階でこのドキュメントを確認しておくことで、テストケースや報告書の内容を読み解く際の判断軸を持ちやすくなります。

テスト仕様書・報告書の読み方——発注者が押さえるべきドキュメント

テスト工程の品質を発注者側で判断するには、ベンダーから受け取るドキュメントの読み方を知っておく必要があります。代表的なものがテスト仕様書とテスト報告書の2種類です。それぞれ記載内容と確認すべきポイントが異なります。

テスト仕様書に含まれる主な項目

テスト仕様書は、「何を・どのような手順で・どの条件で確認するか」を事前に定めたドキュメントです。テスト実施前に発注者へ共有されるケースが一般的で、以下のような項目が含まれます。

• テスト対象範囲：どの機能・画面・APIをテストするかの明示
• テスト観点・条件：正常系・異常系・境界値など、何を確認するかの設計方針
• テストケース一覧：入力値・操作手順・期待結果をケースごとに記載したリスト
• テスト環境：OS・ブラウザ・DBバージョンなど、実施環境の仕様
• 合格基準（Exit Criteria）：どの条件を満たせばテスト完了とするかの定義

発注者として確認すべきは、テスト範囲と合格基準です。要件定義で合意した機能がすべてテスト対象に含まれているか、合格基準が「バグゼロ」のような非現実的なものになっていないかを見ます。合格基準が曖昧なまま進むと、後工程でリリース判断が難しくなるため、仕様書段階での確認が重要です。

テスト報告書の読み方——合否判断と残存リスクの評価

テスト報告書は、テスト実施後にベンダーから提出されるドキュメントです。発注者がリリース可否を判断するための根拠資料として機能します。記載項目は以下が代表的です。

• テスト実施サマリ：総ケース数・実施数・合格数・未実施数の集計
• バグ件数と重大度分布：Severity（重大度）ごとの件数内訳（Critical／High／Medium／Lowなど）
• 修正済みバグ・残存バグの一覧：未解決のバグとその対応方針
• 残存リスクの記述：今回のテストでカバーしきれなかった領域や条件
• 総合評価・リリース推奨可否：ベンダー側の判断コメント

発注者として特に注目すべきは残存バグと残存リスクの2点です。バグ件数の多寡よりも、未修正のバグがどの重大度に分類されており、業務への影響がどの程度かを確認します。たとえば「決済処理が特定条件でエラーになる」がHighのまま残存している場合、リリースの延期や暫定回避策の確認が必要です。

残存リスクは、テストが実施されなかった範囲・条件を示します。「性能テストは今回スコープ外」「特定ブラウザの検証は未実施」といった記述があれば、その領域は本番環境で問題が顕在化する可能性があります。報告書上でリリース推奨とされていても、残存リスクの内容次第では追加テストを求めるか、運用でカバーする手順を整備する必要があります。

ソフトウェアテストの評価を正しく行うには、報告書に書かれた数値を鵜呑みにするのではなく、残存するリスクの内容と業務影響をセットで読む習慣が重要です。

テストの効率化と自動化——発注者が知っておくべき選択肢

テスト効率化の主なアプローチ

テストの効率化を考える際、まず押さえたいのが「リスクベーステスト」という考え方です。すべての機能を均等にテストするのではなく、障害が発生した場合の影響度と発生確率を掛け合わせて、優先度の高い箇所にテスト工数を集中させます。開発予算や納期に制約があるプロジェクトほど、このアプローチが品質と効率のバランスをとる上で有効です。

あわせて「テスト設計技法」の活用も効率化に寄与します。同値分割や境界値分析といった技法を使うと、網羅性を保ちながらテストケース数を絞り込むことができます。発注者がこれらを直接設計する必要はありませんが、ベンダーに「どのテスト設計技法を使っているか」を確認することは、品質管理の観点で意味があります。

自動化が向く領域・向かない領域の判断基準

ソフトウェアテストの自動化は、すべての工程に適用できるわけではありません。自動化が効果を発揮しやすいのは、繰り返し実行する必要があるテストです。

• 自動化が向く領域：リグレッションテスト（修正後の影響確認）、負荷テスト、APIの正常系テスト、デプロイ後の動作確認（スモークテスト）
• 自動化が向かない領域：UIの見た目や使い勝手の確認、仕様が頻繁に変わる画面操作、探索的テスト（テスターが直感的に問題を探る手法）

判断の基準はシンプルで、「同じテストを何度も実行するか」「テスト対象の仕様が安定しているか」の2点です。この条件を満たさない場合、自動化のスクリプト作成・保守コストが手動テストを上回るケースが少なくありません。

代表的なテスト自動化ツールと用途の概要

発注者がベンダーとの会話で出てきやすい主要ツールを整理します。

• Selenium（セレニウム）：ブラウザ操作を自動化するツールの代表格。WebアプリのUI操作テストに広く使われています。導入実績が多い一方、スクリプトの保守に手間がかかる側面もあります。
• Playwright（プレイライト）：Microsoftが開発した比較的新しいブラウザ自動化ツール。複数ブラウザへの対応が容易で、Seleniumより安定した動作が得やすいとされています。
• JMeter（Jメーター）：Apache財団が提供する負荷テストツール。大量アクセス時のサーバー応答速度やシステム限界値を測定する際に用いられます。

自動化を導入した場合の費用・品質・スピードへの影響は以下のように整理できます。初期費用はスクリプト作成の工数分だけ増加しますが、リリースのたびに繰り返す回帰テストはコストが大幅に下がります。品質面では、人為的なテスト漏れが減り、実行結果の記録も自動化されるため、報告書の精度が上がりやすいです。スピード面では、夜間や週末など非稼働時間に自動実行できるため、テストサイクルの短縮が見込めます。一方で、自動化スクリプト自体のメンテナンスが必要になる点は、長期プロジェクトほど計画に織り込んでおく必要があります。

発注者が開発委託時に確認すべきテスト関連の論点

開発委託においてテスト品質を左右するのは、ベンダーの技術力だけではありません。発注者がRFP（提案依頼書）の段階から適切な論点を提示し、契約・プロジェクト管理の各フェーズで確認を続けることが、品質確保の実態を大きく変えます。以下のチェックリストを、ベンダーとの対話や意思決定の場面でご活用ください。

テスト計画・設計段階で確認すること

• テスト計画書の提出時期と記載内容：単体・結合・システム・受け入れの各工程をカバーしているか。工程ごとに目的・実施者・スケジュールが明記されているかを確認します。
• テスト観点表・テスト仕様書の有無：「何を確認するか」が設計されているかどうかが、テストの網羅性を決めます。観点表が存在しない場合、テストの範囲が担当者の裁量に依存するリスクがあります。
• 各工程の完了基準（Exit Criteria）の定義：「テスト件数をこなしたら完了」ではなく、「バグ残存数・重大度ごとの合否基準」が設定されているかを確認します。
• テスト自動化の方針と適用範囲：自動化を導入する工程・対象機能・ツール名を明示してもらいます。自動化がある場合、その維持コストも見積もりに含まれているかを確認します。
• 非機能要件（性能・セキュリティ・負荷）のテスト設計：機能テストのみで非機能要件が抜け落ちていないか、特に本番相当の負荷条件でのテストが計画されているかを確認します。

テスト実施・完了判定で確認すること

• バグ管理票・不具合報告書の形式と共有方法：発見されたバグの件数・重大度・対応状況が発注者にもリアルタイムで見える状態になっているかを確認します。報告書が納品直前にまとめて提出される体制は、問題の早期発見を妨げます。
• テスト報告書に含まれるべき項目：テスト実施件数・合格率・未解決バグの一覧・工程ごとの完了判定結果が含まれているかを確認します。数値の根拠が読み取れない報告書は、品質の判断材料になりません。
• 受け入れテスト（UAT）における発注者の関与方法：UATのシナリオ作成に発注者が参加できるか、また実施期間と判定基準が契約上明示されているかを確認します。
• テスト完了後の残存バグの取り扱い：リリース時点で残存する既知バグの対応方針（修正時期・優先度の判定プロセス）が合意されているかを確認します。

これらの論点は、開発委託の品質管理において発注者が意思決定の主体であることを前提としています。ベンダーに委ねきりにせず、上記の項目をRFPや契約仕様書に盛り込むことで、テスト工程の透明性を担保しやすくなります。

まとめ——テスト工程の全体像と発注者に必要な視点

ソフトウェアテストとは、システムの品質を担保するための検証活動全体を指します。その種類は単体テスト・結合テスト・システムテスト・受け入れテスト（UAT）の4工程に大別され、それぞれ目的・実施者・確認観点が異なります。

各工程の違いを簡単に振り返ると、次のように整理できます。

• 単体テスト：開発者が個々の部品単位で動作を確認する工程
• 結合テスト：複数モジュール間の連携・データの受け渡しを検証する工程
• システムテスト：本番に近い環境で、システム全体の要件充足を確認する工程
• 受け入れテスト（UAT）：発注者が主体となり、業務目線でリリース可否を判断する工程

発注者に求められるのは、全工程を自分で実施する知識ではありません。各テストで誰が・何を・どの基準で確認するかを把握し、ベンダーから提示されるテスト仕様書や報告書の内容を読み解ける状態にあることが重要です。

次のステップとして、担当するプロジェクトのテスト計画書や工程表をベンダーに確認し、4工程のそれぞれに合格基準と担当者が明記されているかを確かめてみてください。その会話の質が、システムの最終的な品質を左右することも少なくありません。