単体テストとは？目的・進め方・結合テストとの違いをわかりやすく解説
システムの開発中に、システム品質の確認を目的として、さまざまな段階でテスト（検証）が実施されます。
「単体テスト」はテスト段階の最初に位置付けられます。
例えば、パッケージ導入の場合は「不足機能を補うために開発されるアドオンプログラムがプログラム設計書通りに機能するか」を確認します。
プログラムの不備により想定した実行結果が得られない（バグがある）場合、プログラムの修正を行うことでバグを解消します。
最終的に、バグを検出する頻度など、事前に定めた完了基準を満たすことでテストが完了します。
単体テストを行うためには、プログラム設計書が正しく、具体的に書かれていることが前提となります。
なぜなら、プログラム設計書をもとに、必要と思われるチェック項目を網羅した単体テスト仕様書が作成され、テスト用のデータが準備されるからです。
そのためにも、プログラム設計書のレビューは、単体テスト実施には不可欠です。
なお、単体テスト仕様書の作成と単体テストの実施はシステム開発会社の責任のもとで行われることが一般的です。
特に、システム開発を発注する場合、発注者側が単体テストに参加することはなく、システム開発会社から単体テスト結果報告書を受け取る形式が一般的です。
具体的なテスト方法は次に示す要素などによって変わります。
- システム開発会社の考え方
- システム開発手法（ウォーターフォール型、アジャイル型など）
- システムの種類（データベースを核としたシステム、Webシステムなど）
- プログラムの機能（バッチ処理プログラム、画面処理プログラムなど）
どんなテスト方法を選択するかについても、単体テストの実施と同様に、システム開発会社が主体となって行われ、発注者側が関与することはほとんどありません。
ただし、「単体テストが完了したプログラムであってもバグが無いとは言い切れない」ことを留意しなければなりません。
システム開発会社がどれだけ入念なテストを行ったとしても、バグが残り、本番稼働開始後に不具合として現れることもあります。
このような潜在的なバグに対応するため、契約不適合責任の明確化や、保守契約の締結も検討する必要があります。
なお、単体テストに合格したプログラム同士、パッケージシステムや他システムのプログラムとを組み合わせておこなう「結合テスト」が、後続のテストとなります。
よくある質問
単体テストの結果を受けた改善策や結合テストへの移行で注意すべき点は？
単体テストの結果を踏まえた改善策の実施および結合テストへの移行では、機能単位での品質確保と、不具合の未解消による後工程への影響を最小化することが重要です。
改善策の実施で注意すべき点
1. 不具合の完全対応と再テストの実施
・発見された不具合は必ず修正し、影響範囲を考慮して再テストを行う。
・影響範囲が広い場合は、該当モジュール以外にも回帰テストを適用する。
2. 原因分析とフィードバック
・不具合の発生原因を分析し、設計やコーディング規約への改善策を反映する。
・テストケースの不足や誤りがあれば修正し、以降の開発工程にも展開する。
3. 対応履歴の記録
・修正内容や再テスト結果を不具合管理票に明確に残す。
・発注者とベンダー間で最新の品質状況を共有する。
結合テストへの移行で注意すべき点
1. 移行条件の明確化
・単体テストで合格基準を満たした機能のみを結合テストに進める。
・基準未達の場合は条件付き移行とし、残課題の対応計画を明確にする。
2. 品質状態の引き継ぎ
・残っている不具合や制限事項を一覧化し、結合テスト担当者に共有する。
・試験環境・テストデータの差異がないよう調整する。
3. ドキュメント・証跡の整備
・単体テスト結果報告書、修正履歴、エビデンス（ログやスクリーンショット）を整理し、結合テスト計画と紐付ける。
単体テストから結合テストへの移行は、品質管理の節目となる重要工程です。発注者は形式的な承認にとどまらず、エビデンスに基づく品質確認と残課題の共有を徹底することで、後工程の手戻りやトラブルを防ぐことができます。
単体テスト工程を外部委託する場合の発注者の留意点は？
単体テスト工程を外部委託する場合は、品質基準・役割分担・成果物要件を明確化し、進捗と品質の可視化を確保することが重要です。
主な留意点
1. 品質基準と判定条件の事前合意
単体テストの合格基準（機能要件の充足率、許容される不具合の範囲など）を契約書や仕様書に明記する。
不具合の重大度分類と対応期限を共有し、判定の基準を統一する。
2. 役割分担と責任範囲の明確化
テスト設計・データ作成・実行・結果報告の各工程で、外部委託先と発注者の担当範囲を明確にする。
不具合修正後の再テストや回帰テストの実施責任も定義しておく。
3. 成果物とエビデンスの仕様定義
テスト仕様書、実行結果、修正履歴、不具合管理票など提出すべき成果物のフォーマットと内容を明確化する。
エビデンス（ログ、スクリーンショット等）の取得方法と保存形式を指定する。
4. 進捗・品質の可視化と報告体制
定期的な進捗報告（例：週次会議）や品質レビューを実施する。
不具合発見率や修正完了率などの指標を活用して品質を数値で把握する。
5. 知識移転とナレッジ共有
テスト中に得られた知見や改善点を発注者側にフィードバックさせ、後続工程や将来案件に活用する。
外部委託ではテスト実務の負担を軽減できますが、品質責任は最終的に発注者が負うため、契約段階から基準・体制・成果物の条件を明確化し、透明性のある管理を行うことが不可欠です。
あわせてこの用語と記事をチェック
この記事の編集者
藤﨑 碩人
大学・大学院では数学を専攻し、IT調達ナビの運営会社である、（株）グローバル・パートナーズ・テクノロジーに新卒で入社した。 公共組織のITガバナンス、マネジメント支援業務に従事し、同社のメディア運営業務にも携わる。応用情報技術者・ITコーディネータ。
