LASSIC Media らしくメディア
テスト計画・テスト設計の外注｜テスト戦略の進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- テスト計画・テスト設計は「何をどこまでテストするか」を決める上流工程であり、ここを外注する際は委託範囲と発注側が準備すべきドキュメントを事前に整理することが重要です。
- JSTQB CTFL v4.0シラバスとISO/IEC/IEEE 29119が定義するテストレベル・テスト設計技法・終了基準を理解することで、外注先とのコミュニケーションを正確に行えます。
- リスクベーステストの考え方を取り入れ、テストケースに要件トレーサビリティを持たせることで、外注後の品質確認コストを大幅に削減できます。
目次
テスト計画・テスト設計とは何か
テスト計画・テスト設計とは、「何を・どこまで・どのような観点で・どの順序でテストするか」を体系的に定義する上流工程であり、テスト実行に先立って品質目標・スコープ・手法・リソース・スケジュールを文書化する活動を指します。
ISO/IEC/IEEE 29119（ソフトウェアテストの国際規格）のPart 2では、テスト活動を「組織レベルのテストプロセス」「テストマネジメントプロセス」「動的テストプロセス」の3層で定義しています*1。テスト計画はテストマネジメントプロセスに属し、テスト実行・終結・報告の前提となる枠組みを確定させる工程です。
JSTQB認定テスト技術者資格Foundation Level（CTFL）シラバス Version 2023V4.0.J02では、テスト計画の主要コンポーネントとして「テスト範囲・アプローチ・リソース・スケジュール・リスク」が挙げられています*2。テスト設計はその計画を受けて具体的な「テスト条件」「テストケース」「テスト手順」を導出する工程です。
この2つは外注でまとめて委託されることが多い工程です。しかし、実態としてはテスト計画が曖昧なままテスト設計だけを外注すると、スコープ齟齬が生じて手戻りが発生します。両工程をセットで整理してから委託するかどうかを判断することが重要です。
テストレベル：単体・統合・システム・受入の役割分担
テスト計画を策定する際、まず「どのテストレベルを対象にするか」を定義します。JSTQB CTFL v4.0シラバスは以下の4つのテストレベルを定義しています*2。
| テストレベル | テスト対象 | 主な目的 | 外注時の留意点 |
|---|---|---|---|
| コンポーネントテスト（単体テスト） | 個々のモジュール・クラス・関数 | コードレベルの欠陥を早期発見 | ソースコードへのアクセスが必要。 テスト容易性の設計が前提。 |
| 統合テスト | 複数コンポーネントの連携部分 | インターフェース欠陥・連携不整合の検出 | インターフェース仕様書・シーケンス図を事前提供すること。 |
| システムテスト | システム全体 | 要件・仕様との整合確認 | テスト環境の準備責任者を明確にする。 本番相当環境を用意できるかが鍵。 |
| 受入テスト（UAT） | ビジネス要件・利用シナリオ | 発注者・ユーザーが受け入れ可否を判断 | 発注側の意思決定者が直接関与することが欠かせない。 シナリオ作成への発注側参加が不可欠。 |
外注でテスト計画を委託する場合、どのテストレベルまでを対象とするかを契約前に明確化する必要があります。単体テストは開発者が行い、統合テスト以降を外注するケースが多いですが、プロジェクト規模・体制によって異なります。テストレベルの境界が曖昧なまま発注すると、スコープの空白や重複が生じます。
テスト設計技法と選択基準
テスト設計とは、テスト計画で定めたスコープ・観点を具体的なテストケースに展開するプロセスです。ISO/IEC/IEEE 29119 Part 4では、テスト設計技法を「仕様ベース技法」「構造ベース技法」「経験ベース技法」の3カテゴリに整理しています*1。
外注の際にどの技法を適用するか発注者が理解していないと、外注先との品質要件の合意が困難になります。主要な仕様ベース技法を整理します。
| 技法名 | 概要 | 適した用途 |
|---|---|---|
| 同値分割（Equivalence Partitioning） | 入力値を同じ振る舞いをするグループ（同値クラス）に分割し、各クラスから代表値を1件テストする。 | 入力フォームのバリデーション、 数値範囲チェックなど。 |
| 境界値分析（Boundary Value Analysis） | 同値クラスの境界（下限値・上限値・境界±1）を重点的にテストする。境界付近で欠陥が生じやすい性質を利用する。 | 数値入力・日付・文字数制限など境界のある処理。 |
| デシジョンテーブルテスト（Decision Table Testing） | 条件の組み合わせとその結果を表形式で整理し、ルールごとにテストケースを設計する。 | 複数条件が組み合わさるビジネスルール（割引計算・承認フローなど）。 |
| 状態遷移テスト（State Transition Testing） | システムの状態と状態間の遷移・トリガーをモデル化し、有効・無効な遷移パスをテストする。 | ワークフロー・ログイン状態管理・注文ステータスなど状態を持つシステム。 |
| ユースケーステスト（Use Case Testing） | ユーザーの操作シナリオ（ユースケース）を基にテストケースを設計する。正常系・代替フロー・例外フローを網羅する。 | システムテスト・受入テストにおける業務シナリオ検証。 |
技法の選択は「テスト対象の特性」「リスクレベル」「利用可能なリソース」によって変わります。外注先に技法の選択を一任する場合も、発注者は「どのような観点を重視するか」をテスト計画書に明示する必要があります。
構造ベース技法（カバレッジ基準）については、単体テストでステートメントカバレッジやブランチカバレッジを達成基準として設定するケースが多くあります。外注契約時にカバレッジ目標値を明記しておくと、品質の客観的な検証が可能になります。
品質目標・終了基準・リスクベーステスト
テスト計画書の核心は「いつテストを終了するか」を定める終了基準（Exit Criteria）です。JSTQB CTFL v4.0シラバスでは、終了基準をテスト計画の必須要素として位置づけており、テスト活動の完了判定に使用します*2。
品質目標と終了基準の設定方法
終了基準は、テストの品質目標（Quality Objectives）から逆算して設定します。代表的な終了基準の指標は以下の通りです。
- 計画テストケース消化率（例：95%以上）
- テストカバレッジ達成率（例：ブランチカバレッジ80%以上）
- 重大欠陥（Critical/High）の未解決件数ゼロ
- 欠陥密度の安定（週次新規欠陥数が目標値以下に収束）
- テスト環境・データの完全性の確認
外注時に終了基準が曖昧な場合、「どこまでテストしたか」を客観的に評価できなくなります。テストが未完了のまま受け入れ検査を通過し、本番リリース後に重大欠陥が発覚するリスクがあります。終了基準は発注者と受注者が契約前に数値で合意することが重要です。
リスクベーステスト：優先度付けの根拠
リスクベーステスト（Risk-Based Testing）とは、テスト対象の欠陥による影響度と発生可能性を評価し、リスクが高い機能・コンポーネントにテストリソースを優先配分する手法です。ISO/IEC/IEEE 29119 Part 1では、リスクベーステストをテストの基本概念として位置づけています*1。
具体的な手順は次の通りです。まず、システムの各機能・コンポーネントについて「欠陥が発生した場合のビジネス影響」と「欠陥が存在する確率（複雑度・変更頻度・過去の欠陥履歴など）」を評価します。次に、その積（リスクスコア）が高い順にテストケースを設計・実行します。
外注でテスト設計を委託する際は、発注者がリスク評価（業務影響度の判断）をあらかじめ行い、外注先に提供する必要があります。業務領域の知識は発注者側にあるため、このリスク評価を外注先に丸投げすることはできません。
テストケースとトレーサビリティの実務
テスト設計の成果物であるテストケースは、要件・仕様との対応関係（トレーサビリティ）を維持することが品質保証の前提となります。JSTQB CTFL v4.0シラバスでは、テストウェアと作業成果物間のトレーサビリティを「テストプロセス全体を通じて維持すべきもの」として定義しています*2。
テストケース設計の3要素
テストケースは一般的に次の3要素で構成されます。
- テスト条件（Test Condition）：テスト対象の何を評価するか（「ログイン機能のパスワード文字数上限」など）
- テスト入力値・事前条件：テストを実行するために必要な入力データと初期状態
- 期待結果（Expected Result）：正しく動作した場合にシステムが返すべき結果
要件トレーサビリティの確保
要件トレーサビリティとは、各テストケースが「どの要件・仕様を検証しているか」を追跡できる状態です。トレーサビリティマトリクス（Traceability Matrix）を用いると、要件の網羅率を可視化できます。
外注時にトレーサビリティが確保されていないと、以下の問題が生じます。
- テスト範囲の漏れが検出できない（未テストの要件が残る）
- 仕様変更時に影響するテストケースを特定できず、再テスト範囲の判断ができない
- 外注先の作業成果物の品質を発注者が客観的に検証できない
外注契約書や作業指示書に「トレーサビリティマトリクスを成果物として納品すること」を明記することで、上記のリスクを減らせます。
テスト計画・テスト設計の外注：委託範囲と発注側の準備
テスト計画・テスト設計の外注を検討する場合、まず「委託できる範囲」と「発注者が担う必要がある範囲」を切り分けることが出発点です。
外注できる範囲と発注者が担う部分
| 工程 | 外注可能な作業 | 発注者が担う作業 |
|---|---|---|
| テスト計画策定 | テスト計画書のドラフト作成。 テスト観点リストの作成。 スケジュール・リソース計画の提案。 |
品質目標・終了基準の決定。 ビジネスリスクの評価・優先度付け。 テスト計画書の承認。 |
| テスト設計 | テスト条件・テストケースの設計。 テスト設計技法の適用。 トレーサビリティマトリクスの作成。 |
要件定義書・設計書の提供。 業務ルール・例外処理の説明。 テストケースのレビュー・承認。 |
| テスト実行設計 | テスト実行順序・依存関係の整理。 テスト環境要件の定義。 テストデータ設計。 |
本番相当のテスト環境・データの用意。 外部システム連携の調整。 |
発注前に準備すべきドキュメント
外注先がテスト計画・テスト設計を開始するには、発注者から以下の情報を提供する必要があります。提供が不十分な場合、外注先は推測でテスト計画を作ることになり、品質目標との乖離が生じます。
- 要件定義書・仕様書：機能要件・非機能要件を文書化したもの（バージョン管理済みのもの）
- システム設計書・アーキテクチャ図：インターフェース仕様・データフロー・状態遷移の情報
- 品質目標・受入基準：何をもってリリース可否を判断するかの定義
- 過去の欠陥・障害情報：リスクベーステストのリスク評価に利用
- 開発スケジュール：テスト計画との整合を取るための情報
これらのドキュメントが整備されていない状態で外注しようとするケースがあります。その場合、テスト計画の策定自体に想定外の時間がかかり、当初スケジュールが崩れます。外注を決める前に、まず社内で要件・仕様の整備状況を確認することを推奨します。
外注先へのRFP（提案依頼書）に記載すべき項目
外注先を選定する際のRFPには、以下の項目を含めると提案の比較評価が容易になります。
- 委託するテストレベル（コンポーネント/統合/システム/受入）の範囲
- 適用するテスト設計技法の指定または提案を求める旨
- 成果物の定義（テスト計画書・テストケース・トレーサビリティマトリクス・テスト完了報告書）
- 終了基準の数値目標（テストカバレッジ・欠陥解決率など）
- 利用するツール（テスト管理ツール・課題管理ツール）の要件
内製対外注の判断軸と必要スキル
テスト計画・テスト設計を内製で行う場合、次の専門知識を持つ人材が必要です。
- テスト設計技法（同値分割・境界値分析・デシジョンテーブルなど）の実務経験
- リスクベーステストのリスク評価手法の理解
- テスト管理ツール（TestRail・Zephyr・Redmineなど）の操作スキル
- 要件・仕様書のレビュー能力（テスト観点の抽出）
- 品質メトリクス（欠陥密度・テストカバレッジ）の分析・報告スキル
これらのスキルを持つ人材を内製で育成・確保するには、相応の時間と工数がかかります。プロジェクト単位での一時的な需要であれば、外注で専門家を起用する方が現実的な場合があります。
外注時に発生しやすい失敗パターンと対策
テスト計画・テスト設計の外注で発生しやすい失敗パターンを整理します。
失敗パターン1：要件定義が未完成のまま外注開始
要件変更が頻繁に発生し、テストケースの大幅な修正が必要になります。結果として工数が膨らみ、スケジュール遅延と追加コストが生じます。対策として、要件定義書を一定程度確定させてからテスト計画の外注を開始することが重要です。
失敗パターン2：終了基準を定量化せずに進める
「テストが十分か」の判断が主観的になり、外注先と発注者の認識齟齬が生じます。外注先は「テストを終えた」と判断しても、発注者からは「まだ不十分」と見られる状況が起こります。契約前に終了基準を数値で合意することで防げます。
失敗パターン3：業務ドメイン知識を外注先に説明せずにケース設計を任せる
業務ルールの例外処理や特殊ケースがテストケースから漏れます。発注者が業務知識をテスト観点として整理し、外注先に提供するレビュープロセスを設けることが有効です。
まとめ：外注成功の3つの判断軸
本稿では、テスト計画・テスト設計・テスト戦略の外注における実務的な論点を整理しました。要点を3つに集約します。
第一に、テスト計画とテスト設計は表裏一体の上流工程であり、JSTQB CTFL v4.0シラバスおよびISO/IEC/IEEE 29119が定めるテストレベル・テスト設計技法・終了基準を理解したうえで委託範囲を設定する必要があります。
第二に、発注者が担う領域（品質目標の決定・ビジネスリスク評価・要件書の整備）と外注先が担う領域（テスト計画書作成・テストケース設計・トレーサビリティ確保）を事前に切り分け、成果物の定義を契約書に明記することが失敗を防ぐ鍵です。
第三に、リスクベーステストの考え方を取り入れ、テストケースに要件トレーサビリティを持たせることで、外注後の品質確認コストを下げ、仕様変更時の再テスト範囲を迅速に特定できます。
よくある質問
テスト計画とテスト戦略はどう違いますか？
テスト戦略（Test Strategy）は組織全体やプログラム単位の方針を定めた上位文書で、テスト計画（Test Plan）はプロジェクト固有の具体的な計画を定めた文書です。JSTQB CTFL v4.0シラバス（2023年）では、テスト計画はテスト戦略から導出し、テスト範囲・アプローチ・リソース・スケジュール・リスクを含む文書と定義されています*2。外注する際は、まず発注者側でテスト戦略（方針）を決めてから、テスト計画の策定を外注先に依頼する流れが一般的です。
テスト設計の外注費用はどのくらいかかりますか？
テスト設計の外注費用は、テスト対象のシステム規模・複雑度・テストレベルの範囲・成果物の定義によって大きく異なります。費用の構成要素はテストエンジニアの工数単価と想定工数の積が基本です。公表されている相場情報は一次資料での確認が難しい状況ですが、見積依頼時にテストケース件数・対象機能数・使用ツールを明示すると、外注先から根拠ある見積を得やすくなります。複数社への相見積と、成果物定義の明確化が費用の適正評価につながります。
アジャイル開発でもテスト計画を外注できますか？
アジャイル開発においてもテスト計画・テスト設計の外注は可能です。JSTQB CTFL v4.0シラバスではイテレーション計画・リリース計画へのテスターの関与が明記されており、スプリントごとにテストスコープを更新する形でテスト計画を運用します*2。外注時はスプリントレビューへの外注先の参加義務・テストケースの更新タイミング・定義完了（DoD）へのテスト観点の組み込み方を事前に取り決めることが重要です。
テストケース設計と仕様書レビューはどちらを先に行いますか？
仕様書レビューを先に行うことが一般的です。仕様書に曖昧な記述や矛盾がある状態でテストケースを設計すると、後から大幅な修正が必要になります。ISO/IEC/IEEE 29119 Part 2では、テスト設計の前段階として要件・設計ドキュメントのレビューをテストプロセスの一部として位置づけています*1。外注先がレビューとテストケース設計を一括で担う場合は、仕様書レビュー結果を発注者に報告し確認を取るステップを作業フローに組み込む必要があります。
テスト終了基準を満たせない場合、リリースを判断できますか？
終了基準を満たさない状態でのリリース判断は可能ですが、残存リスクを明示した上で発注者・ステークホルダーが意思決定する必要があります。JSTQB CTFL v4.0シラバスでは、終了基準の評価とリリース可否の判断を「テスト担当者が発注者に情報を提供し、最終決定は発注者が行う」と整理しています*2。未解決の欠陥件数・リスク内容・暫定対処策をまとめた「リスク受け入れ文書」を作成し、意思決定の根拠を残すことが重要です。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：ISO/IEC/IEEE「ISO/IEC/IEEE 29119 Software and systems engineering — Software testing」Part 1（2022年改訂版）・Part 2（2021年改訂版）・Part 4（2021年改訂版）
- *2 出典：JSTQB（日本ソフトウェアテスト資格委員会）「テスト技術者資格制度 Foundation Level シラバス CTFL Version 2023V4.0.J02」（2023年・ISTQBおよびJSTQB発行）https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf
