はじめに

探索的テストのやり方というよりかは、なぜ探索的テストをするべきなのか？に焦点を合わせて、探索的テストの有用性についてまとめてみる。
※「知識ゼロから学ぶソフトウェアテスト【改訂版】」という良書が分かりやすいのでそれを参考にまとめている。

そもそもの出発点

という事実があるので、効率が良いと言われている探索的テストを取り入れる事で、バグを見つける精度を向上させよう！

という考え方があり、探索的テストを用いる事を検討すべきなのである。

正直この定義だととっつきにくいので、別の言い方で探索的テストとは？を理解すると、

全てのテストを実施するのは、時間的制約から望むべくもない＆テストを行っても全てのバグは見つからない
であれば、いちいちテストケースを書く代わりに、製品(ソフトウエア)の機能を学習した上でテスト設計・実行してバグ報告を並列でやれば手っ取り早い
これは単に新しいテストのスタイルでしかなく、テストケースを書かないだけでやっている事は昔からやっているテストと同じだから、探索的テストのこのやり方でテストケースベースのテストと同等以上の成果を出そう
ただ製品理解、テスト設計・実行を一気にやるのだから素人には無理で、プロとして成熟した一個人のテスト担当者に責任をもってやらせる必要があり、それであれば後から間抜けなバグが見つかったりする事はない

上記のようなものがつまりは探索的テストの本質。
次に探索的テストのテストケースベーステストに対するメリットからなぜ探索的テストか？を見ていく。

テストケースを実行してもバグはあまり出てこない
→テストケースをいちいち事前に書くより、ソフトウエアをテスト(触り)しながら、バグが出そうな部分を考えてテスト実行をする方がいい（ソフトウエアの振る舞いを見て、おや？という部分を考えるみたいに）
（※バグをきちんと見つけれられるテストケースを作れればそれはいいが…実際にはそれは難しい…その理由は以下の項の通り）
テスト設計・ケース作成を早い段階でやろうとしても、ターゲットになるソフトウエアがないため手さぐりになり非効率
- いい加減な要求仕様で仕様が分からない
- テスト対象のソフトウエアを知らない
  という事が起きがちで、早めに作ったテストケースが意味をなさないなんて事も起きがち
テストで重要なのは、以下の2点であり探索的テストのスタイルであればこれが実践できる
（医者が患者の診察をする時と同じイメージで、ソフトウエアの動きを見ていきバグを見つけるのがいいという事）
- テスト実行をしながら、どこかほかの部分に問題がないか？を考えてそこをテストする
- ソフトウエアの弱い所を見つけたらそこを重点的にテストする

※テストケースベースのテストではテストケースに書かれていないものはテストしないので気づけない＋気づいてもWBSの計画線とかのせいでテストできないなんて事になりがち

探索的テストのデメリットは非常に俗人化された作業である事。
もし探索的テストのテストを皆ができるようになればそれは万々歳。
QAの仕事の真骨頂の1つとしては、上記のような探索的テストのいい面を、経験とか勘によらないものにしていくという事があるように思える。