なぜテストの計画が要るか
テストは、案件の終わりで時間を削られやすい工程です。何をどこまで試すかを先に決めておくと、品質を数字と根拠で説明できます。
テストの段と分担
結合テスト・システムテスト・受け入れテストで、目的も、試す人も、使うデータも違います。押して比べてください（2027 年の日程）。
線表（作り物）
テスト計画書と、始める・終える基準
テスト計画書には、方針・体制・環境・日程と、合否を決める基準を書きます。基準はテストの段ごとに決めます。
この案件の基準（作り物） 考え方のヒント
練習: 規程の値から境界値のテストを作る
JSTQB のシラバスは、よく使うブラックボックステスト技法として 4 つ（同値分割法・境界値分析・デシジョンテーブルテスト・状態遷移テスト）を挙げています。ここでは、経費精算の規程の値で境界値を試します。ケースを選んで「このテストで流す」を押すと、隠れた 4 つの不具合を見つけられたかが出ます。
練習: デシジョンテーブルと状態遷移
承認の流れは、金額・上長の休み・部長の休みの 3 つの条件で 8 通りあります。決裁の表（2027 年 4 月 1 日版: 経費の精算は 5 万円以下は上長、超えると部長）で、それぞれの流れを選んでください。
状態表（行けない操作も試す）
不具合の管理（重さ・直す順番・確かめ直し）
見つけた不具合は、1 件ずつ記録して、重さと直す順番を別に付けます。直したら、もう一度試します。
欠陥レポートの項目
練習: この不具合の重さは？ 考え方のヒント
品質の数字と、その限界
バグの数だけでは、品質は分かりません。テストの消化と、まだ直っていない数と一緒に見ます。
練習: 受け入れテストを終えてよいか 考え方のヒント
3/12（金）の夕方。受け入れテストの最終日です。4 つの形のグラフを見て、リーダーとして山本さんに何を勧めるかを選んでください（テストケースは 120。数字は作り物）。
累積の不具合（左の目盛り）未解決の不具合（左）テストの消化率（右）
受け入れテストと検収
受け入れテストは、検収の検査です。合否の基準を前もって合意しておくと、終わりで揉めません。
合否判定基準の例（作り物） 考え方のヒント
テスト完了レポートに書くこと
AI 時代のテスト
テストを書くのは AI が速くなりました。何が正しい結果かを決めるのは、規程を読んだ人です。
チェックリスト
テストの計画を見直したら、チェックを付けてください（この端末にだけ残ります）。考え方のヒント