探索的テストって何？
標準化されつつあるという話も聞きますが、「テストケース自体は書かないが、テストケースに記述されていないことを、テストケースを書いたときとほぼ同じことをするテスト」と理解してます。
探索的テストはテストそのもので、たまたま形式知にしやすいものが、境界値分析などのテスト技法になっているだけで、効果があるかを別にすれば、テスト中に何か考えて行動に移した時点でそれは探索的テストになっていると思ってますし、今は探索的テストと呼ばれているものの中から新しいテスト技法が出てくることもあると思います。
探索的テストは何をするの？
以下のような活動を同時行って繰替えします。
テストする目的を理解すること
ここでは仕様を読んだりヒアリングをしたりすることだと思ってます。テストする機能を理解すること
仕様を理解することに加えて、実際にソフトウェアを動かして、仕様に書かれていない情報を補完することだと思ってます。リスク分析をすること
目的、機能を理解した上で、何に焦点を当てるのかを定めること
焦点を当てるための方法は状況にもよると思いますが、危なさそうものや、弱そうなところに焦点をあてて、どんなテストで取り除くかの方針だけチームと合意が取れればいいので、大雑把にはリスク分析と考えていいと思います。
探索的テストをする理由は？
何か考えてテストしたら勝手に探索的テストになると思っているので、個人的には特に無い気がしてます。
世間的には、テストケースを書く時間や、不要な結果を記録する時間が省かれるので、時間が短縮され、実装の単純ミスや、ユーザビリティの問題が検出しやすくなるというのが理由になると思います。
探索的テストの学習の仕方は？
何か考えて行動すれば探索的テストにはなっていると思うので、探索的テストにフォーカスをあてたトレーニング方法は存在しないと思います。
単にテストする作業を頭で組み立てて、時間対効果の低い作業を省略して実行するに過ぎないので、テストの本を読んで業務で実践していけばいいと思います。
「英文の読み方」が単語を覚えたり文法を覚えたりする地道な作業と分離できないように、勉強していたらどこかで「あ、できてるかも」と思えるようになると思います。
探索的テストのいくつかの型
探索的テストには、決まった形はありませんが、よくある形は存在します。
ものすごく読みにくいですが、以下のドキュメントに分類があります。
https://msdn.microsoft.com/ja-jp/library/jj620911(v=vs.120).aspx
ちなみに、この文書は機械翻訳だから日本語として分かりにくいのではなく、英文読んでもツアーの喩えでけむに巻かれた感があって、結局分からなくなるだけなので、まあ読まなくてもいい気もしますが、読んでみると発見があるかもしれません。
個人的には「The FedEx Tour」というのが面白かったです。
これは、意訳すれば「データの流通の観点」となると思います。
ソフトウェアの中では、現実の宅配便のようにデータが使い回されているので、そのデータという小包の梱包に始まるライフサイクルを無事な配達、あるいは削除、死蔵、果ては誤配達することに着目する観点で、学習するテストである探索的テストらしい観点ではないかと思います。