この記事は、PD-S（システム）試験（仮称）科目B 第4章の2節目、小項目4-2「システムのテストの計画と実施，結果の分析，品質評価」の教科書です。4-1で作ったシステムの品質を確かめる工程——ただしテストは「動かして確認する作業」ではなく、計画し、合意し、設計し、評価して報告する一連のマネジメントだというのがシラバス案のメッセージです（5つの技能のうち3つに「計画書」「報告書」「合意」が入っています）。同値分割・境界値分析といったテスト設計の定番技法も具体例で身につけます。
この節の全体像 — 計画する→設計・実施する→評価・報告する
前提知識：テストの目的と「積み上げ」の構造
図1：テストレベルの積み上げ — 小さく確かめてから大きく確かめる
4-1で登場した単体・結合の先まで含めると、テストは4つのレベルの積み上げで行います：単体テスト（プログラム1つ）→結合テスト(部品間の連携)→システムテスト（全体として要件を満たすか。1-3の非機能要件——性能・障害時の動作——もここで検証）→受入テスト（利用者側が業務の観点で最終確認）。下のレベルで見つかるはずの欠陥を上に持ち越すほど、原因の切り分けが難しくなりコストが増えます。
技能1〜3：テスト計画 — 手法の選択・品質目標・合意
システム要件や特性を踏まえて適切なテスト手法を選択してテスト計画書を作成するスキル及びレビューを通して質の良いテスト計画書を完成させるスキル
テスト手法の2大分類
「要件や特性を踏まえて選択」とは、例えばSoR（4-1）ならデータ整合性の検証を厚く、Webアプリなら負荷テスト（同時アクセス）を厚く——と、システムの性格でテストの重点配分を変えることです。テスト計画書には、対象範囲・テストレベル・使う手法・環境・体制・日程・終了基準（どうなったら終わりか）を定めます。そして4-1で学んだとおり、計画書もレビューで磨きます。
システム要件や特性を踏まえて適切な品質目標を設定するスキル
「テストを頑張る」では管理できません。定量的な品質目標——例えば「テストケースを◯件実施し全件合格」「重要度の高い欠陥は残ゼロ、軽微な欠陥は回避策文書化のうえ◯件まで許容」——を先に決め、これが終了基準になります。目標は一律ではなく、システムの重要度（止まると人命・経営に関わるか）に応じて設定します。
テスト計画書をステークホルダに説明し合意を得るスキル
なぜテストに合意が要るのか。全数テストは不可能＝テストには必ず「やらない範囲」があるからです。どこまで確かめ、どんなリスクを残すか、期間と費用をどれだけかけるか——これは技術者だけで決めてよいことではなく、リスクを引き受ける発注者・利用部門との合意事項です。1-4（クラウドの合意形成）と同じ構図が、テストにもあります。
技能4：テストケースの洗い出し — 同値分割と境界値分析
テスト計画書とソフトウェア設計書を踏まえてテストケースを洗い出し，テスト仕様書を作成するスキル及びレビューを通して質の良いテスト仕様書を完成させるスキル
全数テストができない以上、少ないケースで効率よく欠陥を見つける技法が要ります。代表が次の2つです。「注文数量は1〜100が有効」という仕様を例にします。
図2：同値分割と境界値分析 — 「注文数量は1〜100が有効」の場合
技能5：結果の分析・評価と品質評価報告書
テストの結果を分析・評価して，品質評価報告書をまとめステークホルダに説明するスキル
テストは実施して終わりではなく、結果を品質の証拠として読み解きます。分析の代表的な観点：
- 計画との突き合わせ：予定したケースを全部流せたか。合格率は終了基準を満たすか。
- 欠陥の傾向：どの機能・どの種類に欠陥が偏っているか（偏りがある部分は「まだ出る」可能性が高く、追加テストの候補）。新しい欠陥の発見が減ってきているか（収束の傾向）。
- 残存リスク：未解決の欠陥は何で、業務への影響と回避策は何か。「テストしなかった範囲」も含めて正直に示す。
これらを品質評価報告書にまとめ、ステークホルダに「この品質でリリースしてよいか」の判断材料として説明します。ポイントは、リリース判断は報告を受けた側が残存リスクを引き受けて行う意思決定だということ。「バグが出なくなったのでなんとなく終了」ではなく、基準と証拠に基づいて説明し、合意して終える——計画（技能3）で始まりに合意し、報告（技能5）で終わりに合意する、対の構造です。
混同しやすい概念の整理
| 紛らわしいペア | 違いの核心 |
|---|---|
| ブラックボックス ⇔ ホワイトボックス | ブラック＝仕様（入出力）に着目、中身は見ない。ホワイト＝内部構造（分岐・経路）に着目。単体はホワイト中心、上位レベルはブラック中心 |
| 同値分割 ⇔ 境界値分析 | 同値分割＝グループの代表値を1つずつ。境界値分析＝グループの境目とその隣を突く。セットで使う |
| テスト計画書 ⇔ テスト仕様書 | 計画書＝方針（範囲・手法・体制・終了基準）。仕様書＝個々のテストケースの集合。計画書が親、仕様書が子 |
| テスト終了 ⇔ バグゼロ | 終了＝終了基準（品質目標）を満たし、残存リスクに合意した状態。バグゼロの証明は原理的に不可能 |
| 品質目標 ⇔ 品質評価報告書 | 目標＝テスト前に先に決める基準。報告書＝テスト後に結果を基準と突き合わせて示す証拠。対で機能する |
確認クイズ（4問）
この節の理解度チェックです（当サイト独自の予想問題。公式の出題ではありません）。
「注文数量は1〜100が有効」という仕様に対して境界値分析を行う場合、テストすべき値の組として最も適切なものはどれか。
プログラムの内部構造（分岐や経路）に着目し、コードの通り道を網羅するように行うテスト手法はどれか。
ソフトウェアテストに関する記述として、最も適切なものはどれか。
テスト完了時の品質評価報告書に関する記述として、最も適切なものはどれか。
まとめ：小項目4-2で身につけること
- テストは計画（手法選択・品質目標・合意）→設計・実施（テストケース）→評価・報告のマネジメント。5技能のうち3つが計画書・報告書・合意に関わる。
- 原則：テストは欠陥を見つける活動。「欠陥がない」ことは証明できず、全数テストは不可能——だから基準と合意が要る。
- テストレベルは単体→結合→システム→受入の積み上げ。下で見つけるべき欠陥を上に持ち越すほど高くつく。
- 手法：ブラックボックス（仕様に着目）⇔ホワイトボックス（構造に着目）。ケース設計は同値分割（代表値）＋境界値分析（0, 1, 100, 101）のセットが定石。欠陥は境界に潜む。
- 品質評価報告書＝終了基準との突き合わせ・欠陥の傾向・残存リスクを正直に示し、リリース判断の合意で締める。
関連記事・次に読む
出典（一次情報）
- IPA「プロフェッショナルデジタルスキル（システム）試験（仮称）科目B シラバス（案 Ver0.2）」大項目4・小項目4-2（2026年7月31日更新）[link]。本文中の「技能の例」引用は同シラバス案からの原文引用です。
- IPA「情報処理技術者試験・情報処理安全確保支援士試験 出題範囲等の改定案 Ver.1.0」（2026年3月）
※試験名は仮称、内容は検討段階の案です。試験の形式・時間・配点・合格基準は未公表のため本記事では扱いません。技術解説（テストレベル、同値分割・境界値分析、品質評価など）は一般に確立した知識に基づく当サイトの解説で、シラバスの記載そのものではありません。確認クイズは当サイト独自の予想問題です。正式シラバス公開時に内容を更新します。
