探索的テストってどんなの？
はじめに
新人さんに探索的テストについて簡単に教えたときのスライドを使って、Jasst nano に発表しようかなーと画策してたのですが、断念したのでこちらに供養します。
前置き
こんにちは。ソフトウェアのテストやってる人、かずのりです。
参画しているプロジェクトで、新人さん向けに「探索的テストってどんなの？」って話をしたので、ついでに発表してみます（※してない）
参考文献
本スライドは以下の資料を参考にさせていただきました。感謝！
JSTQB Foundation Levelシラバス
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
探索的テスト入門改訂版/Introduction to exploratory testing
https://speakerdeck.com/goyoki/introduction-to-exploratory-testing
やってみよう！探索的テスト～ハイクオリティな妄想の高速ループ～
https://www.jasst.jp/symposium/jasst18tokyo/pdf/E2.pdf
Session Based Test Management による探索的テストの実践
https://www.ipa.go.jp/archive/files/000064281.pdf
探索的テストとは
JSTQB FLシラバスでは経験ベースのテスト技法に含まれる、ソフトウェアテスト技法のひとつです。
JSTQBのページ
一般的な手動ソフトウェアのように、実行前にテスト設計書やテスト手順書などを作成しません。テスト実行者は（実行後の動作をフィードバックとして）学習し、テスト設計、実行、記録を並行して実施します。
アドホックテストも、テスト分析やテスト設計を行わないテストのやり方ですが、探索的テストは実行中に実際の動きのフィードバックを受けてテスト設計を行いながら実行する、というところが違っています。
探索的テストをやる目的
たくさんバグをみつけること！です。
見つかったバグが修正されることによって、製品がより良いと思われるものになっていきます。
修正されないとしても、未知のバグが既知のバグとなり、あらかじめ制限事項としてお客さんへ説明できたりします。
探索的テストをやってうれしいこと
テスト設計書やテスト手順書など、ドキュメントを作成する時間を、そのままテスト実行に充てることができるという点が特徴です。
そのため、時間がないときに使えるテストですよ、なんて言われたりします。
また、複雑な操作や、テスト実行者の過去の経験・ノウハウなど、テスト設計（手順作成）しづらい部分について実行することができます。
なんだかよさげに見えますが、気をつけた方が良いこともあります。
探索的テストで気をつけた方が良いこと
先述した通り、探索的テストは経験ベースのテスト技法と言われます。「どれだけテストできるか」「どれだけバグを見つけられるか」といったことはテスト実行者によって変わります。「属人性が高い」とよく言われます。
このあたりの経験によって変わるのかなぁというものを以下に列挙してみました。
・テスト設計やソフトウェアテストそのものに関する知識やスキル
・テスト対象の製品仕様や業界への理解（ドメイン知識）
・過去のチケット情報や、他プロダクトのノウハウ（テスト経験）
・想像力、好奇心など
また、テスト結果の残し方は、工夫や検討が必要かと思います。
結果報告の例は後述しますが、実施した内容をどれだけ残すかなどは、探索的テストに使える時間や、テスト実行者のスキル、結果（手順）をテスト設計にどれだけ活用するかなど、プロジェクトの方針などで変わってくるかなと思います。
探索的テストのやり方の例
前述した参考文献などでは、以下の３つが紹介されています。
・フリースタイルの探索的テスト
「どこをテストするか？」が実行者任せなテスト。実際の動きを見てテスト設計をしながら実行し、結果を残すところがアドホックテストとは違います。
・テストチャータを使う探索的テスト
あらかじめ「どういうところをテストするか？」という指針となるものを作成し、その内容に沿ってテストします。テストチャータの書き方は様々です。
・セッションベースドテスト
セッションという単位に時間を区切って行う探索的テスト。探索的テストのミッションなどをあらかじめ明確にして、レポートという形で結果を残します。
上記完全に使い分けることもあれば、「テストチャータを作成するけど粗い粒度で記載してほぼテスト実行者任せ」「テストチャータをベースにしているけど時間を区切って行う」など、組み合わせて使うこともあります。
探索的テストの使い方の例
私がこれまで経験した探索的テストの使い方を例として挙げてみました。
・テスト対象の質を確認する使い方
一部機能の開発を委託した際に、検収のための受け入れテストの一環として実施したり、テストフェーズを本格的に開始する前の、味見のテストとして実施したりしました。
・テストを補完する使い方
普段の手順書を使用したテストを実施した後、２周目のテストとして気になるところをテストしたり、リグレッションテストとして探索的テストを活用したりしました。
もちろんここに記載した以外の活用方法もあります。
開発メンバーもテストメンバーも営業の人たちも一緒になって、一斉に探索的テストをしてバグを見つける、というようなことをしているプロジェクトを経験したこともありました。
また、先日行われたJaSST'24 Tokyoでも探索的テストの活用例の話が出てたりしたようです（別のセッション聞いてたのでまだちゃんと追えていないですが）
探索的テストのコツ
「探索的テストをさあやってください」と突然言われても、テスト経験が少ない人だと何からどう手をつけたらいいのか迷うと思います。
そこで、ちょっとしたコツのようなものを挙げてみました。
・実際に使われる場面を考えてみる
はじめて使う人が間違いやすい操作は？ ベテランの人はどう使っている？
・いじわるな操作を試してみる
連打、電源断、データの削除、拡張子の変更、などなど
・寄り道を考える
エラーを表示させてから成功させる、一度別の操作を挟む、などなど
もちろん「仕様通りに動作するか？」は大事ですが、これらのようなことにも注目してみるといいかもしれません。
探索的テストの結果報告の例
探索的テストの結果の残し方は他にもあると思いますが、とりあえずふたつ挙げてみました。
・普段のテスト結果と同じように報告する
テスト実行者がテストしながら手順や期待値を記載し、OK/NGの結果をつける。結果がOKとなったテストも残すので、どれだけテストしたかわかりやすい。
その分記載の手間がかかり、慣れていない人の場合、記載の仕方に悩んで時間がかかる、などが起きるかもしれません。
手順があるので、通常のテスト設計へフィードバックしやすいです。
・レポートの形で報告する
検出したバグや気になった点をまとめて報告する。細かい手順は記載しないので手間がかからず、実行に時間を充てられる。詳細なテスト内容は見えないので、どれだけテストしたかはわかりにくい。
どちらも長所短所があるので、プロジェクトにあわせて検討が必要になるかと思います。
まとめ
探索的テストは、テスト実行者が考えてテスト設計しながら実行するテストです。
テスト実行者のスキルや経験で効果がかわります。
どういう探索的テストをするか？ 結果をどう残すか？ は考える必要があります。
探索的テストは短い時間でも行うことができるので、色々試してみると面白いと思います。