テスト設計の技法と探索的テスト

テストは全部の組み合わせを試すことはできません。テスト設計の技法は、少ないケースで不具合を見つけやすくするための考え方です。ここでは「年齢（整数）を入力する欄。18〜64 歳なら登録できる」という仕様を例にします。

どの技法を使うか

• 入力欄・数値の範囲 → 同値分割＋境界値分析（ほぼ必ずセットで使う）。
• 条件の組み合わせで結果が変わる（料金・権限） → デシジョンテーブル。
• 手順や状態がある（注文・会員登録・ワークフロー） → 状態遷移テスト。
• 環境や設定の組み合わせが多い → ペアワイズ。
• どれでも最後に → エラー推測と探索的テストで補う。

落とし穴：境界の「以上・未満」を仕様で確かめずにテストすると、期待する結果そのものが間違います。また、技法で作ったケースは「仕様に書いてあること」しか試せないので、書かれていない動き（同時操作・通信の切断・戻るボタン）は別に考えます。

同値分割と境界値分析をくわしく

同値分割は、同じ扱いになる値をグループ（同値クラス）に分け、各グループから代表を1つ選ぶ技法です。境界値分析は、不具合が多いグループの境目と、その両隣を試す技法です。2つはほぼ必ずセットで使います。例は「18〜64 歳なら登録できる」年齢の欄です。

境界の両隣だけを試す「2値」が基本で、より慎重に見るときは境界の内側の隣（19・63）も加える「3値」にします。

落とし穴：「64 歳まで」が「64 歳を含む」のか、仕様で確かめずに期待結果を書くと、テストそのものが間違います。また、画面で止めても API に直接送れば通ってしまうことがあるので、無効な値はサーバー側でも拒否されるか確かめます。

デシジョンテーブルは、条件の組み合わせと結果を表にして、抜けをなくす技法です。料金・割引・権限のように、複数の条件で結果が変わる機能に向きます。

表にすると「会員でなくクーポンもない」ケース4が抜けていることに気づけます。こうした仕様の抜けを見つけられるのも技法の効果です。

条件が増えると組み合わせは倍々に増えます（3つで 8 通り、4つで 16 通り）。結果に影響しない条件は「—（どちらでもよい）」にまとめて列を減らします。表を作ると、仕様書に書かれていない組み合わせ（ケース4）が見つかり、PdM への質問になります。

状態遷移テストは、対象が持つ「状態」と、何をしたら次にどの状態になるか（遷移）を図や表にして、テストを作る技法です。注文・会員登録・申請の承認のような、手順や状態がある機能に向きます。

矢印のない操作は、ボタンを隠すだけでなく、API を直接呼んでも拒否されるかまで確かめます。状態と操作を縦横に並べた状態遷移表を作ると、図では見落としやすい「この状態でこの操作をしたら？」をすべて洗い出せます。

ペアワイズは、「どの2つの因子の値の組み合わせも、少なくとも1回は出てくる」ようにケースを選び、組み合わせの数を減らす技法です。不具合の多くは1つか2つの条件の組み合わせで起きる、という経験則にもとづいています。

例：ブラウザ（Chrome・Firefox・Safari）×言語（日・英・中）×会員（無料・有料・法人）。全部なら 27 通りですが、次の 9 通りで2つずつの組み合わせはすべて出ます。

手で作ると間違えやすいので、PICT などのツールで作るのが一般的です。注意：3つ以上が同時にそろったときだけ起きる不具合は見逃すことがあるので、決済のように重要な組み合わせは別に追加します。ありえない組み合わせ（Safari と Windows など）は制約として除きます。

エラー推測は、経験から「不具合が出やすい入力や操作」を狙って試すことです。技法で作ったケースの最後に、次の早見表から足します。

見つかった不具合の傾向を、チームの早見表に足していくと、次の機能のテストでも使える財産になります。

テストケースは、誰が実行しても同じ結果を判定できるように書きます。いちばん大事なのは、あいまいさのない期待結果です。

細かく書きすぎると保守が大変になります。手順が自明な部分は「チェックリスト」（確かめる観点だけを並べた一覧）で十分なこともあります。回帰テストで何度も使う重要なケースは細かく書き、自動化の候補にします。

探索的テストは、決まった手順書を使わず、触りながら学び、次に試すことをその場で考えていくテストです。手順書どおりのテストでは見つからない、想定外の使い方による不具合を見つけるのに向いています。ただし、思いつきで触るのではなく、目的と時間を決めて行います。

チャーター（目的の一文）

チャーターは、そのテストの目的を一文にしたものです。よく使う形は「〔対象〕を、〔方法・道具〕を使って調べ、〔見つけたい情報〕を見つける」です。

カート画面を、通信を遅くして（開発者ツールの Slow 4G）
何度も操作して調べ、二重注文や表示の食い違いを見つける

チャーターがあると、「何を見たか・何を見ていないか」をあとで説明できます。思いつきで触るアドホックテストとの違いはここにあります。

セッションベースのテスト管理は、探索的テストを時間の区切り（セッション）で管理するやり方です。セッションごとにチャーターを1つ決め、終わったら記録と振り返りを残します。

セッションは、1つのチャーターに集中する時間の区切りで、60〜90 分ほどにすることが多く、長くても 2 時間までにします（決まった長さはなく、慣れや対象に合わせて調整します）。終わったら、他の人と短く振り返り（何を試したか・何が分かったか・次に何を調べるか）を行います。

• 試したこと・気づいたことを時刻つきで簡単にメモする（後で「どこまで見たか」を説明できるように）。
• 見つけた不具合、仕様の疑問、次に調べたいことを分けて書く。
• 画面の録画やスクリーンショット、開発者ツールの通信の記録（HAR ファイル）を残すと、再現しにくい不具合の報告に役立ちます。
• 何度も確かめたい手順が見つかったら、テストケースや自動テストにする。

探索的テストで「次に何を試すか」に迷ったら、経験則（ヒューリスティック）の観点を順に当てると、考えが広がります。

観点のリストはチームで育てます。過去の不具合を観点ごとに分類しておくと、どこを探索すべきかが分かりやすくなります。