はじめに
テスト工程に入ったとき、こんな状態になっていないでしょうか。
- とりあえずテスト項目を作り始める
- 機械的にテストを消化する
- エビデンスをなんとなく残す
この状態でも「作業」は進みますが、品質は上がりません。
なぜならテストは単なる作業ではなく、設計して、証明する活動だからです。
この記事では、テストの全体像を「学校のテスト」に例えながら解説します。
テストの全体像
まずは流れを整理します。
テスト計画（設計）
テスト計画は、どんなテストをするかを決める工程です。
学校でいうと、「テスト問題を作る先生の仕事」です。
- テスト観点を考える → テストの範囲と配点を決める
- テスト項目に落とす → 問題を作る
適切な範囲からバランスよく問題を作成する。
それがテスト設計です。
テスト実施（証明）
テスト実施は、問題を解いて、正しさを証明する工程です。
学校でいうと、「テストを受けて答案を書く生徒の仕事」です。
- テストを実施する → 問題を解く
- エビデンスを残す → 解答用紙に書く
正しく解いて解答用紙を作成する。
それがテスト実施です。
各フェーズの役割
テスト観点を考える → テストの範囲と配点を決める
システムのテスト
- どの機能・条件をテストするか洗い出す
- 正常系・異常系・境界値などの観点を整理する
- 重要度に応じて優先度（重み）を決める
学校のテスト
- どの単元を出すか洗い出す
- 基本問題・応用問題のバランスを整理する
- 配点を決める
これを意識すると
重要なところを漏らさず、バランスよくテストできるようになる
これを意識しないと
- 重要な観点が抜ける
- 簡単なケースばかりテストしてしまう
- テストの優先度が分からなくなる
テスト観点が定まっていないと、検出すべきバグを見つけられない
テスト項目に落とす → 問題を作る
システムのテスト
- 観点ごとに具体的な入力値・操作を定義する
- 期待結果（どうなれば正しいか）を明確にする
- 第三者でも実施できるレベルまで具体化する
学校のテスト
- 実際に解く問題を作る
- 正解（模範解答）を明確にする
- 問題文だけで解けるように具体化する
これを意識すると
誰が見ても同じ解釈になるテストになる
これを意識しないと
- 何をすればいいか分からないテストになる（答えがない問題になる）
- 人によって期待結果が変わる（採点者によって点数が変わる）
- 人によって意図が変わる（回答者によって解釈が変わる）
項目が曖昧だと、テスト結果も信用できない
テストを実施する → 問題を解く
システムのテスト
- テスト項目に従って操作を行う
- 実際の動作結果を確認する
- 手順通りに再現性のある実施をする
学校のテスト
- 問題を順に解く
- 計算や思考を進める
- 自分の解答を導く
これを意識すると
テスト項目通りに正しく検証できる
これを意識しないと
- 手順を飛ばす・変える
- 再現確認ができないテストになる
- テスト漏れが発生する
実施がズレると、正しいテスト項目でも意味がなくなる
エビデンスを残す → 解答用紙に書く
システムのテスト
- 実行結果をスクリーンショットやログで残す
- 入力値と結果の対応関係を記録する
- OK/NGの判定を明確にする
学校のテスト
- 答えを解答用紙に書く
- 途中式を書く
- 採点できる形でまとめる
これを意識すると
第三者が見ても正しさを判断できる
これを意識しないと
- 何を確認したのか分からない
- OKの根拠が不明になる
- 結果を確認できない
エビデンスが弱いと「やったこと」ではなく「やったつもり」になる
おわりに
テストが「作業」になるか、「品質を作る活動」になるかは、この全体像の理解で決まります。
学校のテストで考えるとシンプルです。
範囲を決めずに問題を作りますか？
問題と関係ない答えを書きますか？
やらないはずです。
システムのテストも同じです。
テストとは「問いを設計し、答えを証明する活動」です。
- テスト観点：何を問うか
- テスト項目：どう問うか
- テスト実施：どう解くか
- テストエビデンス：どう答えるか
この繋がりを意識するだけで、テストの質は大きく変わります。
そして実務では、この「答え」が正しいかどうかを第三者が確認する工程（レビュー）が入ります。
ここまで含めて、初めて品質が担保されます。
テストは実施して終わり（解答して終わり）ではありません。
結果を他人に証明できて（採点されて）初めて完了するのです。