あらすじ
「テスト項目、これで全部かな…」。
画面に並ぶテストケースの一覧を前に、ユウタは眉間にしわを寄せていた。初めてひとりで任されたテスト設計。自分の観点が正しいのか、抜けているものはないのか、どうしても自信が持てない。
意を決して先輩の席へ向かい、「先輩、これで漏れてないか不安です…」と相談したところ、先輩はゆっくり椅子を回して微笑んだ。
「じゃあ、テスト観点を広げるコツ、教えてみようか」
ユウタ
「このテストケースなんですけど…一応、自分なりに全部洗い出したつもりなんです。でも“これで本当に大丈夫？”って思っちゃって…。
お客さまに渡す前に抜け漏れがあったらと思うと、落ち着かなくて」
先輩
「なるほどね。初めて任されるときって、どうしても不安になるよね。でも大丈夫、視点を広げる“型”を持っておくとテスト設計はぐっと安定するよ」
ユウタ
「型…ですか？」
先輩
「うん。今日は“効率的にテストケースを作るための3つのメソッド”を紹介しよう。これが身につくと、観点の抜け漏れも減るし、設計スピードも上がるよ」
メソッド①：ハッピーパスと異常系で整理する
先輩
「まずは“ハッピーパスと異常系”。テストケースって、まず“正常に動くシナリオ（ハッピーパス）”を固めるところから始めると整理しやすいんだ」
ユウタ
「まず正常系から…そのあとに異常系を考える感じですか？」
先輩
「その通り。例えば“ログイン機能”なら、正常にログインできるパターンを押さえる。そのあとに“パスワード間違い”“未登録メールアドレス”“アカウントロック”みたいな異常系を広げていく。
正常をベースに考えると、抜けが減るんだよ」
ユウタ
「なんか…異常系から考え始めて混乱してたので、ちょっと納得です」
先輩
「テストは“正常→異常”の順番で考えると、視点がぶれにくくなるよ」
メソッド②：境界値分析で“バグが潜みやすい場所”を狙え
ユウタ
「境界値って、よく聞くんですけど…正直、まだピンと来てなくて」
先輩
「一番バグが潜みやすいのが“境目”なんだ。例えば、入力可能な文字数が1〜20字だったとする。 もちろん“1文字、20文字”が入力できることは確認するよね。でも、それだけで安心しちゃいけない。本当にバグが出やすいのは…？」
ユウタ
「えっと…0文字とか、21文字…ですか？」
先輩
「そう！ “ギリギリＯＫな値”と“ギリギリＮＧな値”。この境界線の両側を突くのが境界値分析の基本なんだ。」
先輩
「境界値分析のポイントは“仕様の上下を攻める”。
さらに最近は“null、空文字、オーバーフロー、特殊文字”なんかも忘れずに入れると良い。
特にフォーム入力は、ここを押さえるとバグ検出率が一気に上がるよ」
ユウタ
「なるほど…境界って“ギリギリの値”だけじゃないんですね。例外的な値も含む、と」
先輩
「そうそう。“仕様の外側”を想像できるようになると、一人前のエンジニアに近づくよ」
メソッド③：観点マッピングで抜け漏れゼロへ
ユウタ
「観点マッピングって、マトリクスを作るやつですよね？ うまく使いこなせる気がしなくて…」
先輩
「難しそうに見えるけど、使うと一気に視界がクリアになるよ。
縦軸に“機能一覧”、横軸に“テスト観点（CRUD、権限、通知、表示制御など）”を並べて、チェックを埋めていくだけ。
“機能 × 観点”で整理すると、漏れが見つけやすくなる」
ユウタ
「たしかに…一覧で見えると“この機能は権限観点が抜けてるな”とか気づけそうです」
先輩
「そうそう。しかも、これを1回作っておくと次のプロジェクトでも使い回せる。
“自分専用テンプレート”が増えていく感じで、どんどん設計が楽になるよ」
ユウタ
「テンプレート…！ それなら短時間でクオリティ上げられそうです」
先輩
「ユウタ、今日学んだ3つのメソッドを使えば、テストケースはもっと自信を持って作れるようになるよ。
“観点が抜けてるかも…”っていう不安は、知識じゃなくて“型”で減らすんだ。慣れていけば、むしろ“観点を拾うのが楽しい”って思えるようになるよ」
ユウタ
「…なんか、ちょっと見えてきました！
まずはハッピーパスを固めて、境界値を洗い出して、観点マップでチェックですね！
よし、もう一回作り直してみます！」
先輩
「いいね。その意気。困ったら、また気軽に相談してね」
応用ヒント
・ハッピーパスは“ユーザーストーリー”と紐づけると設計が安定する
・境界値は「通常の境界値」「異常値」「極端値」で3セット考えるクセをつける
・観点マッピングはプロジェクト共通テンプレートにするとチーム全体の品質が向上する
・異常系のテストデータは、早い段階で多めに準備しておくと設計がスムーズ
・テスト観点はレビュー時に説明しやすい言葉でまとめておくと、合意形成が早くなる