0. はじめに
新卒エンジニアの皆さん、この瞬間に心当たりはありませんか？
先輩「よし、この機能の実装OKだね！じゃあ、テストお願い！」
自分「はい！（よっしゃ終わったー！）」
～数分後～
自分「（仕様書の前で固まりながら）…で、何をテストすればいいんだ…？」
僕は、この「手が止まる瞬間」を何度も経験しました。
とりあえず正常に動くケース（ハッピーパス）だけテストしてみるものの、レビューでは先輩から「この場合はどうなる？」「この観点が抜けてるよ」という指摘の嵐。
そんな僕が、『この1冊でよくわかる ソフトウェアテストの教科書』を片手に、自分なりに「これなら迷わないかも」というテストの考え方を整理してみました。
本記事は、テストの専門家による完璧な解説ではありません。
僕のような新卒・初心者エンジニアが、同じように悩む同志へ送る、
明日からのテストに迷わないための実践的な思考ノートです。
0-1. 罠：僕らが陥りがちな「とりあえずテスト」
教科書の話に入る前に、僕がよくやってしまっていた失敗を紹介します。
- 🚨思いつきランダムテスト: なぜその値なのか根拠なく、思いついた値をいくつか入れてみる。（例：とりあえず
100円と5000円で試してみるか…） - 😇 ハッピーパス症候群: ユーザーが想定通りに操作する、一番基本的な流れしかテストしない。（例：
1000円の商品を買ったら10ポイント付くことだけを確認する） - 🥷俺様の聖人君子データ: 完璧に整形されたテストデータを作成し、バリデーション等を考慮しない。（例：電話番号の形式が全て
080-XXXX-XXXXのデータ）
残念ながら、これだとソフトウェアが本当に壊れやすい「境界」や「例外的な状態」を全く確認できません。ではテストって、どうやってやればいいんでしょうか。
というかそもそも、ソフトウェア開発において、テストって何のためにやるんでしょうか？
1. 前提：ソフトウェアテストとは
本書によれば、ソフトウェアテストとは「欠陥を取り除いて、ユーザーの要求を満たす、品質の良いソフトウェアを作るための手段」と定義されています。
これは、以下の二つの視点に整理できますね。
ソフトウェアにおける「欠陥」
当然のことながら、ソフトウェアにおいて欠陥、つまり不具合や誤動作は誰もが起こしたくないでしょう。
しかし、ソフトウェアは人間が作るもの。初めから完璧なものを作ることは不可能です。
だからこそ我々エンジニアには、製品に含まれる欠陥を限りなくゼロに近づけるために「効果的・効率的なテスト技術や手法」が求められています。
ソフトウェアにおける「品質」
品質とは、ユーザーの要求を満たし、ユーザーに価値を提供することです。
操作が複雑だったり、見た目に満足できなければ、ユーザーにとってそのソフトウェアの価値はゼロに等しいでしょう。
そのため、欠陥を意識するのは大前提として、使い勝手や操作など「ユーザーにとっての価値1」もテストで担保することが重要です。
つまり、テストをする意義とは「欠陥の除去と品質の担保」だと言うことですね！
では、これを達成するために、我々はテストをどうやって進めていけば良いのでしょうか。
もちろん、この問いを突き詰めると「テスト工程」2や「テスト手法」3といった専門的な話になりますが、それは一旦、専門家や先輩方にお任せしましょう（笑）
そのため繰り返しになりますが、本記事では「観点」と「手法（神器）」という2つの側面から、明日からのテストに迷わなくするための考え方を紹介していきますね。
2. 本論：「テストの質」を支える2つの観点
常に2つの観点を持っておくことが推奨されます。
V&V
1つ目は「Verification(検証) と Validation(妥当性確認)」の視点です。
Verification(検証)とは、作成されたソフトウェアが「開発仕様書どおりか」を確認することで、
Validation(妥当性確認)とは、「ユーザーの要求どおりか」を確認することです。
| Verification(検証) | Validation(妥当性確認) | |
|---|---|---|
| 目的 | 正しく作っているか？ (Are we building the product right?) |
正しいものを作っているか？ (Are we building the right product?) |
| 確認の対象 | 開発仕様書 | ユーザーの要求 |
| 欠陥の種類 | 不具合や誤動作 | 仕様漏れ |
実は、ソフトウェアにおけるすべての欠陥はこのどちらかに分類できるんです！
互いを補完する、双方向の視点になっているんですね。
一般的に開発担当者は立場上、開発仕様書を重視するため、
テスト担当者はこの「V＆V」の視点でテストをすることが必要です。
なお、自社系の企業では開発とテストで担当者が同じことも多いようです。
プロダクトに関わる全員が、常に「ユーザーの要求は何か」「ユーザーにとって問題にならないか」を考えるべきかもしれません。
Never, Must, Want
2つ目は、「Never, Must, Want」の視点です。
これは、ソフトウェアへの要求を3つの異なる観点から整理する考え方です。1
| Never | Must | Want | |
|---|---|---|---|
| 分類 | リスク | 基本機能 | 要望 |
| 観点 | あってはならないこと | できなければならないこと | できたらよいこと |
| 具体例 | 会員情報が流出する | ログイン・ログアウトができる | 生体認証に対応している |
V&Vが少し理論的なアプローチだったのに対し、こちらは非常にシンプルで実践的ですね。
日々の動作確認の中でも、「これはMustだから絶対に確認しよう」といったように、すぐに応用できそうです！
実際の現場では、NeverとMustのみの観点でテストケースを網羅することが多いのが現状です4。「仕様通りだが改善すべき点」や「ユーザビリティへの気づき」はメモに残しておくなどして、なるべくWantの観点を忘れないようにしましょう。
と、観点はざっとこんな感じでした。
この2つの「観点」を持つことで、闇雲だったテストに「目的」という光が見えてくるはずです。
ではここから後半戦として、その目的を達成するための具体的な「手法」、つまり冒頭の「とりあえずテスト」を卒業するための「3種の神器」を見ていきましょう。
3. 本論：「テストケースを効率的に見つける」ための3種の神器
本書では同値分割や境界値分析、状態遷移テストといった専門用語がたくさん出てきました。
最初は「うっ…」となりましたが、これらは難しい理論ではなくテストケースを効率的に見つけるための、便利な「考え方のテンプレート」だったんだと気付きました！
ここでは、そんな便利なテンプレートのうち「3種の神器」を紹介します！
3-1. 同値分割（ユーザーの操作をグループ分けできないか？）
「同値分割」と呼ばれる考え方です。
「同じような結果になる入力値を一つのグループと見なそう」というものですね。
例えば、ポイントサイトで「20歳以上が対象のキャンペーン」があったとします。
-
25歳で試してOKなら、きっと30歳でも40歳でもOKなはずですよね。 - 逆に
15歳でNGなら、きっと18歳でもNGなはず。
このとき、入力値をやみくもに試すのではなく、以下のようにグループ分けして考えます。
| グループ名 | 条件 | テストデータ(例) | 結果の期待値 |
|---|---|---|---|
| グループA | 20歳以上 | 20, 30 | OK |
| グループB | 20歳未満 | 15, 19 | NG |
この2つのグループから代表的な値を一つずつ選べば、効率的にテストができます。
（例：15歳と25歳）
このように同値分割の考え方を用いれば、闇雲なテストをなくし、本当に意味のある最小限のケースに絞り込むことができますね！
3-2. 境界値分析（そのグループの“境目”はどこか？）
「境界値分析」と呼ばれる考え方で、テストの肝となるものです。
バグは仕様の「境目」で最も発生しやすいという原則に基づいた手法ですね。
先ほどの「20歳以上が対象のキャンペーン」の例で言えば、今回の境目は「19歳と20歳」です。
ここでテストすべきなのは、まさしくこの境界の値なんです。
-
19歳（NGになるはずの境界） -
20歳（OKになるはずの境界）
さらに、ありえない値（無効値）もテストします。
-
0歳や-1歳を入れたらどうなる？ -
200歳のような巨大な値は？ -
"二十歳"のような文字列は？
結果はこうなりますね！
| グループ名 | テストデータ(例) | 結果の期待値 | 観点（なぜこの値か） |
|---|---|---|---|
| 境界値 | 20, 19 | OK / NG | 仕様の境界を正しく判定できるか |
| 無効値 | 0, -1, 200 | エラー | 仕様範囲外の値を正しく拒否できるか |
| 無効値 | 二十歳 | エラー | 不正なデータ型を正しく拒否できるか |
このように境界値分析の考え方（意地悪なユーザーになりきるイメージ）を持つだけで、テストの質は一気に上がります！
なお無効値のケースが多すぎる場合、問題の根本は実装そのものにあるかもしれません。
仕様を見直し、より堅牢なバリデーションを設けることをお勧めします。
3-3. 状態遷移（この機能を使っているときの“状態”は？」）
「状態遷移」と呼ばれる考え方で、Webアプリケーションにおける、ユーザーの状態に応じた振る舞いの変化を、網羅的に検証するための手法です。
こう聞くと難しく聞こえますが、実は意外とシンプルです！
「今のユーザー（あるいはシステム）は、どんな状態（モード）だろう？」と考えながら読み進めていただくのがおすすめかもしれません。
例えば、ECサイトの「クーポン利用機能」をテストするなら、
クーポン利用時におけるユーザーの行動は以下のようになりますね。
このようにユーザーの「状態」を洗い出し、掛け合わせることで「ログイン済みで、クーポンを持っていて、カートが5000円以上の場合は…」といった、下記のようなテストケースが浮かび上がってくるんです！
| ケース | ログイン状態 | クーポン保持 | カートに商品 | 5000円以上 | クーポン適用結果 |
|---|---|---|---|---|---|
| 1 | 済み | ◯ | ◯ | ◯ | OK |
| 2 | 済み | ◯ | ◯ | ✕ | NG (金額不足) |
| 3 | 済み | ◯ | ✕ | ✕ | NG (カートが空) |
| 4 | 済み | ✕ | ◯ | ◯ | NG (クーポンなし) |
| 5 | 未ログイン | ◯ | ◯ | ◯ | NG (要ログイン) |
一見複雑に見える機能でも、状態遷移の考え方を用いるだけで、テストすべきケースが明確になります。さらに、単一の条件だけでは見つけられない「条件の組み合わせ」によって発生するバグも発見できる、一石二鳥の手法です！
以上が、テストケースを効率的に見つけるための「3種の神器」でした。
（ちなみに、これらの手法はすべてブラックボックステスト5に分類されます）
特に最後の「状態」を考えるアプローチは、無意識のうちに実践していた方も多いかもしれません。
しかし、今回のように「状態遷移という名前と型を意識する」だけで、今後のテストでより強力な武器として使いこなせるようになるはずです！
4. 実践：「観点」と「神器」でテストケースを洗い出してみる
さて、最後にこれまで紹介した「2つの観点」と「3種の神器」を使って、実際にテストケースを洗い出すとどうなるか、具体例を見ていきましょう。
なお、テスト観点のVerification（検証）は全テストが持つべき必須の土台で、
一方でWant (あると嬉しいこと)は、「仕様通りだが改善すべき点」や「ユーザビリティへの気づき」など、改善提案としてメモやチケットに残すと良いでしょう。
# テスト観点
- Verification（検証）
- [x] 開発仕様書に沿った仕様になっていること
- Validation（妥当性の確認）
- [x] （ユーザビリティ）ユーザーが迷うことなく直感的な操作でキャンペーンに応募できること
- [x] （UI/UX・信頼性）ユーザーが応募フォームの入力中に不安やストレスを感じないこと
- Must（できなければならないこと）
- [x] 20歳以上のユーザーは正しく応募できること
- Never（あってはならないこと）
- [x] 19歳以下のユーザーは応募できてはならないこと
- Want (あると嬉しいこと)
- [x] 例1）年齢が足りずエラーになる際、画面上部にメッセージが出るだけでなく、
年齢入力欄のすぐ下に「20歳以上の方のみご応募いただけます」と表示されること。
- [x] 例2）応募完了後、ホームページに直接戻るのではなく、「応募が完了しました！」という専用の確認画面が表示されること。
# テストケース
機能：20歳以上限定キャンペーンのポイント付与機能
- 【神器1: 同値分割】正常系
- [x] 25歳が応募し、正常にポイントが付与されること
- 【神器2: 境界値分析】境界値・無効値
- [x] 20歳が応募し、ポイントが付与されること
- [x] 19歳が応募し、エラーメッセージが表示され弾かれること
- [x] 0歳や-1歳、"二十歳"といった無効な値で応募し、エラーになること
- 【神器3: 状態遷移】別の状態
- [x] 非ログイン状態で応募ページにアクセスし、ログインページにリダイレクトされること
このように、まず「観点」でゴールを定め、次に「神器」で具体的な手段を見つける、という思考のプロセスを書き残すだけで、思考が整理され、レビューしてくれる先輩にも意図が伝わりやすくなりますね。
5. まとめ： 僕らは、まだ完璧じゃなくていい
ここまで、テストの「観点」と「神器」について見てきました。
こうして思考の型に当てはめていくだけで、闇雲にテストする状態から抜け出せる気がしませんか？
今回紹介した観点や技法は、テスト理論のほんの一部です。
我々のような新卒・初心者エンジニアにとって大切なのは、いきなり完璧なテストを目指すのではなく、自分なりの「型」を持って、少しずつテストの解像度を上げていくことだと、僕は思います。
本記事が、同じように悩む同志のテストへの迷いを乗り越える、一つの武器になれば幸いです。
最後まで読んでいただき、ありがとうございました！
6. 参考
【書籍】
【記事】
-
現代におけるユーザーにとっての「価値」は非常に多様化している。深掘ってみると結構面白かったので、興味のある方はぜひご参照ください！（狩野モデルにおける品質の分類 / 出典：ソフトウェア品質向上プラットフォーム - Qbook） ↩ ↩2
-
ソフトウェア開発の大きな流れにおいて、「いつ、どの範囲を」テストするかを定めた段階的な計画のこと。個々の部品（単体テスト）から製品全体（システムテスト）へと、徐々に範囲を広げながら品質を確認していく。 ↩
-
各テスト工程で、効率的にバグを見つけ出すための具体的なテストケースの作り方や考え方のこと。内部構造を見ずに機能仕様だけを頼りにする「ブラックボックステスト」などが代表的な手法として知られており、「同値分割」や「境界値テスト」など、本書ではより詳細なものが紹介されている。 ↩
-
ソフトウェア開発における「鉄の三角形」と呼ばれる、有名な制約に基づいている。スコープ(品質)・リソース(コスト)・時間(納期)の3要素は互いにトレードオフの関係にあり、すべてを同時に満たすことはできない、という原則。こちらも面白かったので、興味のある方はぜひ！（プロジェクト管理のトライアングルと、それがチームにもたらすメリットとは？ - asana.com） ↩
-
ソフトウェアの内部構造（コード）には触れず、「仕様」だけを見るテストの種類のこと。この中の技法として本記事で紹介した「同値分割テスト」などが存在する。対義語はホワイトボックステスト。 ↩