
はじめに
Developer&Designer Advent Calendar2025🎄22日目を担当します、品質推進部の吉満です。QAエンジニアとして、プロダクト開発チーム横断で、品質改善支援、品質文化醸成に取り組んでいます。
皆さん、突然ですがこんな経験はありませんか?
「仕様書に記載のパターン全てテストしたのに、リリース後、利用ユーザーからバグ報告が来た……」
これ、ソフトウェア開発七不思議のひとつですよね。「仕様書には『Aボタンを押す』としか書いてなかった。まさかユーザーが『Aボタンを秒間10回連打』するなんて...!
でも、ユーザーが実際どんな使い方をするか、リリース前にすべて想定できません。それに、リリース直後は問題なかったが、時間の経過とともに(連携する他システムの影響で)想定外の状態になってしまった!なんてこともあります。
そこで、そんな「想定外」をあぶり出す、「探索的テスト(Exploratory Testing)」を、ご紹介します。 この記事で、探索的テストにどんなメリットがあって、開発現場にどのような効果をもたらすのか、探索的テストの魅力を皆さんに知ってもらえたら嬉しいです✨
2025年の締めくくりに、バグを見つけるスキル、インストールしてみませんか?
- はじめに
- 探索的テスト = コンパス片手に冒険すること
- そもそも「探索的テスト」って?
- なぜ今、探索的テストなのか?(3つのメリット)
- でも勘違いしないで!これは「銀の弾丸」じゃない ⚠️
- 実践編:ECサイトで、Let's 探索! 🛒💡
- 冒険に出る前に
- まとめ:明日の30分、ちょっと冒険してみませんか?🧭
探索的テスト = コンパス片手に冒険すること
ちょっとその前に、テスト技法の話 📝
本題に入る前に、少しだけ真面目な話をさせてください。 皆さんご存知かもしれませんが、ソフトウェアのテスト技法には大きく分けて3つのタイプがあります。
-
ブラックボックステスト: コードを気にせず、仕様に基づいてUI上で確認する
-
ホワイトボックステスト: 内部ロジックやコードに着目して網羅的に確認する
-
経験ベースのテスト: テスターの知識・スキル・経験則に基づいて確認する
今回ご紹介する「探索的テスト」は、この3つ目の「経験ベースのテスト技法」の代表格です。 つまり、仕様書やツールではなく、あなたの「経験値」こそが最大の武器になるテスト技法なのです。
そもそも「探索的テスト」って?
従来のテスト(スクリプトテスト)が「地図(仕様書)を見ながら、スタンプラリーする」ものだとしたら、探索的テストは「コンパスだけを持って、気になる場所を自由に探検する」スタイルです。
-
「あれ? ここの挙動、なんかモッサリしてない?」
-
「この入力欄に、絵文字を入れたらどうなる?」
-
「ここで通信切れたら、データはどうなる?」
テストを実行しながら、その場の「違和感」を頼りに、即興で次のテスト手順を考えて、すぐに試す。そして得られた結果からまた学ぶ。このサイクルを高速で回すのが探索的テストです。ここでいう「コンパス」とは、価値あるバグを見つけるための「指針」や「判断基準」のことです。「好きにテストして」と言われると、どこをテストしたらいいか迷ってしまいますが、「この範囲を、こういう視点で探索する」という方向性を示してから、テストをはじめます。
なぜ今、探索的テストなのか?(3つのメリット)
「仕様書がないなんて不安!」と思うかもしれません。でも、これには大きなメリットがあるんです。
メリット1:「仕様書の隙間」に潜むバグが見つかる 🕵️♀️
設計書や仕様書に「ハッピーパス(正常系)」「エラーパス(異常系)」は書かれていても、「意地悪な操作」までは書かれていません。探索的テストでは、あなたが「ちょっと意地悪なユーザー」になりきることで、ドキュメントの隙間に隠れていたバグを見つけ出せます。バグが見つかったときの「あっ!」という感覚は、たまりません。
メリット2:とにかく速い!開発サイクルの相棒 🚀
開発チームのリードタイム短縮が求められる今、さまざまな操作パターンを載せた分厚いテスト仕様書を書いて承認をもらう時間なんてありません。「機能ができたよ!」と言われたら、その場ですぐに触り始めてフィードバックを返す、という高速ループが回せるので、開発チーム全体のスピードが上がります。
メリット3:テスター自身の「レベル」が上がる 🆙
ただクリックするだけの作業とは違い、「どこが弱そうか?」「どんな不整合が起きそうか?」と常に頭フル回転で考えるので、システム知識や勘所が驚くほど鋭くなります。気付けば「あなたが触るとバグが見つかる」とチームで頼られる存在になれるかも。
でも勘違いしないで!これは「銀の弾丸」じゃない ⚠️
ここで、とても大事なことをお伝えします。
「すごい! 明日から全部、探索的テストにしよう!」と思った方、ちょっとストップ!✋
探索的テストは、決して万能な「銀の弾丸」ではありません。 従来のスクリプトテスト(手順書通りのテスト)が不要になるわけではないのです。
-
スクリプトテスト(守り):
-
「機能が当たり前に、毎回ちゃんと動くこと」を保証する。テストの網羅性担保やリグレッションテストにはこちらが必須です。
-
-
探索的テスト(攻め):
-
「未知のバグ」や「使いにくさ」を見つけ出す。スクリプトテストでは拾いきれない部分をカバーします。
-
つまり、この2つは「補完関係」にあります。 スクリプトテストという「地図」で迷わないようにしつつ、探索的テストという「コンパス」で宝(バグ)を探す。この両輪があってはじめて、鉄壁の品質が守られるのです。
実践編:ECサイトで、Let's 探索! 🛒💡
さあ、心構えができたところで実践です。 みんな大好き「ECサイト」を舞台に、探索的テストの例を3つご紹介します。あなたは今、リリース直前のECサイトを前にしたプロの探検家です。いざ、探索的テストをはじめましょう!
ミッション1:残り1点の在庫を奪い取れ!📦
【狙い】 データの整合性とタイミング
スクリプトテストなら「カートに商品を入れて購入できること」を確認して終わりです。でも探索的テストなら?
🎮 アクション: 「残り1点」の人気商品をカートに入れます。ここで、スマホとPCの両方で同じ画面を開き、「せーの!」で同時に「注文確定」ボタンを押してみましょう。
👾 発見できるバグ: もし排他制御(ロック)が甘ければ、「在庫がないのに注文できてしまった」という、店長が真っ青になるバグが見つかるかもしれません。処理が重なるタイミングを攻める、これぞ探索的テストの基本です。
ミッション2:割引クーポンの裏ワザ!?🎫
【狙い】 複雑な条件分岐と「戻る」ボタンの挙動
🎮 アクション: 「5,000円以上で1,000円OFF」のクーポンを適用させます。一度カートに5,000円分入れて割引されたことを確認。 そこからが本番です。決済直前の確認画面でブラウザの「戻る」を押し、商品を削除して4,000円にします。 そして、涼しい顔で「進む」ボタンを押します。
👾 発見できるバグ: 再計算が行われず「条件を満たしていないのに割引されたまま」購入できてしまうかも!?画面表示と裏側のデータ処理のズレを狙った、まるでゲームの隠しコマンドのようなバグハントです。
ミッション3:イライラしたユーザーになりきって連打せよ!😡
【狙い】 UIの堅牢性と二重処理防止
🎮 アクション: 「 クレジットカード決済の「支払う」ボタンを押します。ローディングがグルグル回っていますね。 そこであなたは「反応が遅いぞ!」と怒ったふりをして、ボタンを激しく連打してください。あるいは、その瞬間にWi-FiをOFFにしてみるのもありです。
👾 発見できるバグ: ボタンのガード処理が甘いと、「二重決済」が発生したり、注文メールが何通も届いたりします。「お金」に関わる重要なバグを見つけた時の「達成感」は、探索的テストの醍醐味です。(もちろん、発生を防ぐことが最重要ですが!)

冒険に出る前に
これから探索的テストを始めるあなたへ。 迷子にならずに成果を出すために、「コンパス(指針)」となる具体的な考え方を5つ紹介します。この考え方を装備して、宝(バグ)探しの冒険に出発しましょう!
1. テストチャーター(ミッションの定義)
「今日は何を狙うか」決める:漠然と対象システムを触るのではなく、「今回は『決済機能』を『通信切断』の観点で攻める」といった短いミッションを決めます。これが「進むべき方角」を示すコンパスになります。
2. タイムボックス(時間の枠組み)
30分〜60分で必ず区切る:時間を制限することで、「ダラダラと関係ない機能まで触ってしまう」ことを防ぎます。限られた時間で成果を出そうとする集中力が、探索の深さを増します。
3. ペルソナ(なりきりプレイ)
「誰」の視点で見るかを決める 「ITに不慣れなユーザー」「新規登録者」「システムを攻撃する悪意ある第三者」など、特定の誰かになりきります。自分個人の感覚ではなく、その人ならどう感じるか?という視点が、探索の幅を広げます。
4. 探索ツアー(観光ガイド)
比喩を使って巡回ルートを決める:探索的テストの有名な手法です。「スーパーモデルツアー(見た目 - UIだけチェック)」や「FedExツアー(データの配送だけ追跡)」「危険地域ツアー(バグが多く発生している機能周辺をチェック)」「ガイドブックツアー(チュートリアル、オンラインヘルプの通りに操作)」など、ツアーのテーマを決めます。別名、ツアーリングテストといいますが、探索のアイデアが膨らみます。
ツアーのアイデアについては、こちらの書籍も参考になります。
5. チートシート(虎の巻)
「よくあるバグ集」を手元に置く:先に挙げたような「バグ探しのアイデア集」や「入力値のリスト」を横に置いてテストします。次にどんな操作をすべきか迷った時、すぐに次の手を教えてくれる「攻略本」のような存在です。
まとめ:明日の30分、ちょっと冒険してみませんか?🧭
いかがでしたか?
探索的テストは、従来のテスト手法を否定するものではなく、それを強力に補完する手法です。 「ユーザーならこうするかも」「システムはここを見落としているかも」という想像力と仮説を武器に、システムを探索するテスト手法です。
明日の仕事で、機能確認が終わった後の30分だけ。 仕様書(地図)を一旦置いて、「ユーザーになりきって自由に」触ってみてください。きっとそこには、まだ誰も見つけていない「宝物(バグ)」が眠っているはずです🎁✨
それでは、良いクリスマスと、バグのない良いお年を!

吉満 恵子 Keiko Yoshimitsu
ITガバナンス本部 品質推進部
大手メーカーやITベンチャー企業などさまざまなプロダクトの品質保証を担当し、テスト方針策定、プロセス改善、アジャイルQA推進などをリード。2023年パーソルキャリアに入社。現在は、部門横断で品質状況可視化や、品質文化醸成の取り組みを推進している。
