境界値テストで効率よくバグを狙う
限られた時間で、どこを試すか
すべての入力パターン・すべての操作順序をテストする時間は、たいていのプロジェクトにはありません。だとすれば、限られた時間をどこに投じるかがテスト設計の本質になります。経験的に、本番で踏まれるバグの多くは「普通の入力」ではなく「境界」で起きています。桁数の上限、空の入力、連打、ブラウザバック、遅い回線。これらは実装者が想定しづらく、かつテストの優先順位からも漏れやすい領域です。
境界値・異常系に絞る戦略
全組み合わせを試す網羅的なテストではなく、「壊れやすい場所」を先に決めて重点的に叩く戦略に切り替えます。目安として、以下の5パターンに絞るだけで、コストをかけずに検出率を大きく上げられます。
1. 文字種の境界
- 絵文字・サロゲートペア（🎉など4バイト文字）
- 結合文字・ゼロ幅文字（Unicode正規化で長さが変わる入力）
- SQLインジェクション記号（
'";）をそのまま許容しているか - 右から左に書く言語（アラビア語など)での表示崩れ
2. 桁数の境界
- 空文字・空白のみの入力
- DBカラムの上限文字数、および「上限+1文字」
- 数値項目の0・負数・浮動小数点の誤差が出る値
3. 連打・多重送信
- 送信ボタンのダブルクリック
- ネットワークが遅い環境でのボタン連打
- 同一リクエストを別タブで同時に送る
4. 戻る操作・ブラウザバック
- フォーム送信後にブラウザバックして再送信
- タブを閉じて別タブから同じセッションで操作を続ける
- ページ遷移中に戻る・進むを繰り返す
5. タイムアウト・低速回線
- Chrome DevToolsのネットワークスロットリングで3G相当に落とす
- APIレスポンスが数秒返らない間にユーザーが別操作をする
- セッショントークンの有効期限が操作中に切れる
実際に落ちた例
ある登録フォームでは、氏名欄に4バイト文字（絵文字）を入力すると、DB側の文字数カウントとフロント側のJavaScriptの文字数カウントがずれ、フロントでは「20文字以内」で通過したのにDB保存時にエラーになっていました。原因は、JavaScriptの.lengthがサロゲートペアを2文字として数える一方、DBのバリデーションは正しくカウントしていたという実装のズレです。境界値（上限文字数）と文字種（サロゲートペア）が重なったことで初めて発見できたバグでした。
別の例では、決済ボタンの二重クリックで注文が2件作成されるバグがありました。通常の操作テストでは1回しかクリックしないため気づかず、「連打」という異常系を明示的にテスト観点に入れて初めて再現しました。
テスト設計に落とし込む
5パターンをそのままチェックリストにして、機能ごとに当てはめるだけでも効果があります。
- 入力を受け付けるフィールドをすべて列挙する
- 各フィールドに「文字種」「桁数」の境界値を当てる
- 送信・決済など不可逆な操作には「連打」「戻る操作」を必ず当てる
- 外部APIに依存する処理には「タイムアウト」を当てる
- 時間が余ったら、それ以外の組み合わせに広げる
すべての機能に全パターンを当てる必要はありません。不可逆な操作（決済・削除・送信）や、外部に公開される入力（氏名・コメント欄）を優先すれば、限られた時間でも実害の大きいバグを先に潰せます。
Bugoon での実践
境界値テストで見つかったバグは、再現条件が特殊なほど報告時の情報量が重要になります。Bugoonのウィジェットは、発生画面のスクリーンショットにアノテーションを付けて、直前の操作ステップを自動で記録した状態でバグ報告を送信できます。「絵文字を含む氏名で登録し、20文字ちょうどで送信した」といった境界値特有の再現条件も、スクリーンショットと操作履歴があれば言葉で説明し直す手間が減ります。報告はそのままGitHub Issueに連携できるため、境界値テストで見つけた小さなバグも、修正フローに乗せたまま管理できます。