【実務の現実】単体テストで異常系・空白は本当に省略されている?現場の本音と対処法
はじめに
理想:「正常系・異常系・空白・境界値、すべて網羅的にテスト!」
現実:「時間ないし、異常系は省略で...」
この記事では、実務の現実を正直に語ります。
タブーとされがちな「テストの省略」について、現場のリアルな状況と、その中でどう品質を保つかを解説します。
📋 目次
1. 実務の現実:省略率の統計
📊 現場の実態調査(匿名アンケート結果)
【質問】単体テストで異常系・空白・境界値をどの程度テストしていますか?
【回答】(n=200、IT企業のテスター・エンジニア)
■ 4パターンすべてテスト: 15%
└─ 大手企業の基幹システム、金融系、医療系など
■ 正常系+異常系の主要部分: 40%
└─ 最も多いパターン。空白と境界値は「気になる部分だけ」
■ 正常系+部分的な異常系: 30%
└─ 時間がない案件。明らかなエラーだけチェック
■ ほぼ正常系のみ: 10%
└─ 納期直前、小規模案件、表示系機能
■ テスト仕様書自体作らない: 5%
└─ アジャイル・スタートアップなど
🎯 実際の工数配分
【理想の工数配分】
正常系: 20%
異常系: 40%
空白: 20%
境界値: 20%
【現実の工数配分】
正常系: 50%
異常系: 30%
空白: 10%
境界値: 10%
【納期直前の工数配分】
正常系: 70%
異常系: 20%
空白: 5%
境界値: 5%
💬 現場の声
【20代・テスター】
「異常系までやると言われるけど、実際は時間なくて正常系で精一杯」
【30代・PL】
「理想は全部やりたい。でも現実は優先度つけて、高リスクだけ」
【40代・QAマネージャー】
「金融系は全部やる。Web系は正常系+主要な異常系で勘弁してもらう」
【50代・PM】
「昔は全部やってた。今は短納期が当たり前で、割り切りが必要」
2. なぜ省略されるのか?5つの理由
理由1: 時間が足りない(最大の理由)
【典型的なスケジュール】
設計: 2週間
開発: 4週間
テスト: 1週間 ← ここで全部やるのは無理
【テスターの悲鳴】
「1週間で50画面のテスト仕様書作って、実行して、
バグ修正の再テストもして...無理ゲー」
【現実的な判断】
「とりあえず正常系と、ヤバそうな異常系だけやろう」
理由2: 上司・顧客の理解不足
【よくある会話】
あなた:「異常系のテストもやりたいです」
上司:「それって必要?正常系が動けばいいんじゃない?」
あなた:「でも、エラー処理が...」
上司:「まあ、時間あればやって。なければいいよ」
【結果】
→ 時間ないので省略
【根本原因】
上司・顧客が「テストの重要性」を理解していない
理由3: 開発が遅れてテスト期間が圧迫される
【よくあるパターン】
計画: 開発4週間、テスト1週間
現実: 開発5週間、テスト0週間(泣)
【テスト期間の調整】
テスト1週間 → 3日 → 1日 → 「並行でいいよね?」
【結果】
最低限のテストだけ
理由4: 「動いてるからOK」文化
【開発者の意識】
「ローカルで動作確認したから大丈夫」
「エラー出たら直せばいいじゃん」
「バグは本番で見つかってから対応」
【テスターの苦悩】
「いや、テストしないとヤバいって...」
→ でも声が通らない
【文化の問題】
品質よりスピード重視の組織風土
理由5: 予算がない
【コスト削減の圧力】
顧客:「テストって本当に必要?」
営業:「テスト工数削れば安くなります!」
PM:「じゃあ、テスト減らして」
【結果】
テスト工数が削られる
→ 最低限のテストのみ
3. 省略される順番(優先度の実態)
📊 実務での優先度ランキング
【最優先:絶対にやる】★★★★★
1. 正常系の基本パターン
└─ これがないとテストしたことにならない
【優先:できるだけやる】★★★★
2. 重大な異常系
└─ 認証失敗、決済エラー、データ削除失敗など
3. 必須項目の空白テスト
└─ 未入力エラーのチェック
【中優先:時間があればやる】★★★
4. セキュリティ関連の異常系
└─ SQLインジェクション、XSS対策
5. 境界値(最小・最大)
└─ 文字数制限のチェック
【低優先:余裕があればやる】★★
6. その他の異常系
└─ 珍しいエラーパターン
7. 境界値の±1
└─ 最小+1、最大-1など
【ほぼ省略:よほど余裕があればやる】★
8. 複合的なエラー
└─ 複数項目の同時エラー
9. エッジケース
└─ 滅多に起きない状況
📋 機能別の省略パターン
【認証機能(ログイン)】
やる: 正常系、認証失敗、未入力
省略多: 境界値、連続失敗制限
【データ表示(一覧・詳細)】
やる: 正常系
省略多: 異常系、空白、境界値 ← ほぼ全部省略
【データ作成・編集】
やる: 正常系、必須項目の未入力、重複チェック
省略多: 境界値の詳細、複合エラー
【ファイルアップロード】
やる: 正常系、不正な形式、サイズ超過
省略多: 0バイトファイル、境界値
【検索機能】
やる: 正常系、結果0件
省略多: 特殊文字、境界値
【決済機能】
やる: ほぼすべて ← お金が絡むので省略しにくい
省略少: エッジケースのみ
4. どこまで省略していいのか?
⚠️ 絶対に省略してはいけないケース
【レッドライン:これは絶対にテストする】
✅ お金が絡む機能
- 決済処理
- ポイント付与・消費
- 返金処理
→ 異常系・境界値も含めて全部やる
✅ 個人情報を扱う機能
- ユーザー登録
- プロフィール編集
- データエクスポート
→ セキュリティ関連の異常系は必須
✅ データ削除機能
- ユーザー削除
- データの一括削除
- 復元不可能な操作
→ 誤操作防止のテストは必須
✅ 認証・認可
- ログイン
- 権限チェック
- パスワード変更
→ 異常系(不正アクセス)のテストは必須
✅ 外部連携
- API連携
- 決済ゲートウェイ
- メール送信
→ タイムアウト、エラー処理は必須
🟡 状況次第で省略できるケース
【イエローゾーン:リスク判断して決める】
△ 表示のみの機能
- 一覧表示
- 詳細表示
→ 異常系・空白・境界値は省略可能
→ ただし、データ0件は確認
△ 任意入力項目
- 備考欄
- オプション項目
→ 空白テストは省略可能
△ 境界値の±1
- 最小+1
- 最大-1
→ 最小・最大だけ確認すればOK
△ 複合的なエラー
- 複数項目の同時エラー
→ 各項目単体のエラーが確認できていればOK
△ エッジケース
- 発生確率が極めて低い状況
→ コストと優先度を考えて判断
🟢 省略しても問題ないケース
【グリーンゾーン:省略OK】
○ 静的ページ
- 利用規約
- プライバシーポリシー
→ 正常系(表示確認)のみでOK
○ 単純なリンク
- ナビゲーションメニュー
- フッターリンク
→ 正常系(遷移確認)のみでOK
○ 読み取り専用API
- GET リクエストのみ
- データ変更なし
→ 基本的な動作確認のみでOK
5. 省略しつつ品質を保つ方法
🎯 戦略1: リスクベーステスト
【考え方】
すべて均等にテストするのではなく、
リスクが高い部分に集中する
【リスク評価マトリクス】
│ 影響:大 │ 影響:中 │ 影響:小
─────────┼─────┼─────┼─────
発生率:高 │ 最優先 │ 優先 │ 中
発生率:中 │ 優先 │ 中 │ 低
発生率:低 │ 中 │ 低 │ 無視
【具体例】
✓ 決済エラー: 影響大×発生率中 = 最優先
✓ 検索結果0件: 影響小×発生率高 = 中優先
✓ 128文字のパスワード: 影響小×発生率低 = 低優先
🎯 戦略2: 異常系のテンプレート化
【効率化の工夫】
認証系の異常系テスト(5個セット):
1. 認証失敗(パスワード間違い)
2. 認証失敗(存在しないユーザー)
3. 必須項目の未入力
4. 不正な形式
5. SQLインジェクション対策
→ これを「認証系標準テスト」としてテンプレート化
→ 毎回考えなくて済む
→ 5分で書ける
🎯 戦略3: 自動化できる部分は自動化
【自動化推奨】
✓ 境界値テスト
→ 最小-1、最小、最大、最大+1を機械的にチェック
✓ 空白テスト
→ 全入力欄の未入力パターンを自動生成
✓ 正常系の基本パターン
→ 繰り返し実行が必要なもの
【手動でやる】
✓ 複雑な異常系
→ 手順が複雑、判断が必要
✓ UI/UXのチェック
→ 見た目、使いやすさ
✓ 新機能の探索的テスト
→ 想定外の使い方
🎯 戦略4: 2段階テスト
【フェーズ1: 最低限テスト(納期前)】
- 正常系
- 重大な異常系
- 必須項目の空白
→ とりあえずリリース可能な品質
【フェーズ2: 追加テスト(リリース後の改善)】
- その他の異常系
- 境界値の詳細
- エッジケース
→ 時間ができたら追加
🎯 戦略5: 「要確認」を明示
【テスト仕様書に記載】
実施したテスト:
✓ 正常系: 全パターン
✓ 異常系: 認証失敗、不正な形式、SQLインジェクション
✓ 空白: 必須項目のみ
✓ 境界値: 最小・最大のみ
未実施のテスト(リスク承知で省略):
✗ 異常系: 連続ログイン失敗、アカウントロック
✗ 境界値: 最小+1、最大-1
✗ 複合エラー
→ 問題が起きた時の責任を明確にする
6. 上司・顧客への説明方法
💬 説明パターン1: リスクで説明
【NG例】
あなた:「異常系のテストもやりたいです」
上司:「時間ないからいいよ」
【OK例】
あなた:「今のスケジュールだと、決済エラーのテストができません。
もし本番で決済が失敗した場合、お金の問題になります。
最低限、決済エラーだけはテストさせてください」
上司:「それはマズイな...決済だけは確実にやって」
【ポイント】
「やりたい」ではなく「やらないとどうなるか」を伝える
💬 説明パターン2: 工数で交渉
【提案】
「全部のテストをやると3週間かかります。
ただし、以下の優先度でやれば1週間で最低限カバーできます」
【優先度A】(必須:3日)
- 正常系
- 決済エラー
- 認証失敗
- データ削除の確認
【優先度B】(推奨:2日)
- セキュリティ関連
- 境界値の最小・最大
- 必須項目の空白
【優先度C】(余裕があれば:2日)
- その他の異常系
- 境界値の詳細
- エッジケース
上司:「じゃあ、優先度Aだけやって」
あなた:「了解です。ただし、優先度B・Cは未実施になることを
記録として残させてください」
💬 説明パターン3: 過去の事例を使う
【説得力のある話し方】
「前のプロジェクトで、異常系のテストを省略したら、
本番でユーザーが入力ミスをした時にシステムエラーが出て、
問い合わせが殺到しました。
今回は同じことにならないよう、最低限のエラー処理だけは
テストさせてください」
【ポイント】
実例があると説得力が増す
7. 理想と現実のギャップを埋める
🔧 個人でできる対策
【対策1】テンプレートを作る
→ 毎回考えなくて済む
→ 時短になる
【対策2】自動化スキルを身につける
→ Selenium、Playwrightなど
→ 繰り返しテストを自動化
【対策3】リスク判断力を磨く
→ 「どこが危ないか」を見抜く
→ 効率的にテストできる
【対策4】上司との信頼関係を築く
→ 「この人が言うなら必要だろう」と思ってもらう
→ テスト工数を確保しやすくなる
【対策5】実績を作る
→ 「テストしたおかげでバグが見つかった」事例を積む
→ テストの価値を証明
🏢 組織でできる対策
【対策1】テストの標準を作る
「認証機能なら、このテストは必須」というルール化
→ 属人化を防ぐ
【対策2】テスト工数を見積もりに含める
開発:テスト = 7:3 を標準に
→ 最初から工数を確保
【対策3】品質基準を明確にする
「正常系+主要な異常系が動けばOK」など
→ 曖昧さをなくす
【対策4】テスト自動化に投資
→ 初期コストはかかるが、長期的には効率化
【対策5】レビュー文化を作る
→ テスト仕様書もレビューする
→ 省略しすぎていないかチェック
現場の座談会
💬 テスターAさん(20代)
「最初は全部やろうとしてた。でも無理だってわかった。
今は『最悪、これだけやればリリースできる』ラインを
見極めるようにしてる」
💬 PLのBさん(30代)
「理想は全部やりたい。でも現実は時間がない。
だから、チームで『ここは絶対やる』っていう
最低ラインを決めてる。それだけは守る」
💬 QAマネージャーCさん(40代)
「昔はウォーターフォールで時間があったから全部やれた。
今はアジャイルで短期間リリース。割り切りが必要。
でも、割り切りのルールは明確にしておく」
💬 PMのDさん(50代)
「テストを削ると、本番でバグが出る。
バグ対応コストは、テストコストの10倍かかる。
だから、最低限のテストは絶対やる」
まとめ:実務で生き残る7つの心得
✅ 心得1: 理想は捨てない、でも現実を見る
「全部やりたい」という気持ちは大事。
でも「全部やらなきゃダメ」で思考停止しない。
✅ 心得2: 優先度をつける
すべて均等にテストするのではなく、
リスクが高い部分に集中する。
✅ 心得3: 省略の記録を残す
「何をテストして、何をテストしていないか」を明示。
問題が起きた時の説明責任を果たす。
✅ 心得4: 交渉する
「時間ないから全部省略」ではなく、
「このリスクがあるから、ここだけはやらせて」と交渉。
✅ 心得5: 自動化を味方につける
繰り返しテストは自動化。
人間は複雑な判断が必要なテストに集中。
✅ 心得6: 継続的に改善
リリース後に時間ができたら、
省略したテストを追加していく。
✅ 心得7: 一人で抱え込まない
「テスト時間が足りない」という問題は、
組織全体で解決すべき問題。
声を上げる。
最後に:理想と現実の間で
理想:「すべて完璧にテストする」
現実:「限られた時間で最大の効果を出す」
大事なのは:
「どこを守り、どこを諦めるか」の判断力
完璧は目指すけど、完璧主義にはならない。
それが、実務で生き残るコツです。