はじめに
テストケースを増やすことは簡単ですが、減らすことは難しいです。
なぜなら、削ったテストケースの先にある不具合は自分の責任になるからです。
そこで、スティーブ・ジョブズの言葉を借ります。
What pride is being questioned at or throw away, love is asked in what defend.
(何を捨てるかで誇りが問われ、何を守るかで愛情が問われる)
この言葉を「テスト設計」に置き換えて考えます。
何を「捨てるか」
捨てるべきテストケースでエンジニアの誇りが問われます。
テストは増やせば増やすほど安心に見えます。
しかし、すべてをテストすることが必ずしも最適とは言えません。
設計の意図を理解し、影響を生まないテストケースを捨てる選択こそが、エンジニアの誇りになります。
何を「守るか」
守るべきテストケースでエンジニアの愛情が問われます。
一方で、決して手放してはいけないテストケースがあります。
なぜなら、品質を守ることは何よりも重要だからです。
ユーザーの一日を想像し、影響を受けるテストケースを守る選択こそが、エンジニアの愛情になります。
捨てるべきテスト / 守るべきテスト
１．境界
- 捨てる
境界から十分に離れた値の確認
（例：x ≤ 10 のときの「5」「6」） - 守る
境界値そのものの確認
（例：x ≤ 10 のときの「9」「10」）
２．入力制御
- 捨てる
UI制御をなぞるだけの入力確認
（例：機械的な maxlength や disabled の確認） - 守る
サーバー側で意味が変わる入力確認
（例：想定外入力・改ざん・直接リクエスト）
３．条件分岐
- 捨てる
結果に影響しない条件の全組み合わせ
（例：機械的な網羅テスト） - 守る
成立・不成立が切り替わる代表ケース
（例：各条件が効いていることの確認）
４．責務の境界
- 捨てる
ライブラリやフレームワークの保証をなぞるテスト - 守る
業務ロジックとして定義された振る舞い
５．影響範囲
- 捨てる
失敗しても利用者に影響しないケース
（例：ログに残るだけ） - 守る
失敗した瞬間に問い合わせが発生するケース
（例：業務停止・業務遅延）
６．変化耐性
- 捨てる
安心のためだけの確認 - 守る
将来壊れやすい箇所の確認
（例：仕様変更・データ増加・日付跨ぎ）
７．デグレ履歴
- 捨てる
今まで問題になったことのない平常ルート - 守る
過去に障害・ヒヤリハットがあった箇所
おわりに
テスト設計とは、すべてを確かめることではありません。
何を捨て、何を守るかを選択することです。