昨年クックパッドでお話をさせていただいたときに複数の方から「Testingの記録は残しているのですか？」と質問がありました。そのときは「残してません」と回答したのですが、ずっとどこかで気になっています。（以降、Testingは「探索的テスト」と記載します）
わたしたちのチームでは「探索的テストを記録すること」は求められていないですし、仮にですよ、今日から突然記録しはじめたら「なにやってんの？」「miwaさんがおかしなことをやりはじめた！」と大騒ぎになるのは目に見えています。だから、これまで考えてみることすらしなかったのですが、あれから二ヶ月たった今でも、どこかで気になっているのは、もともと「探索的テストが好き」で、だから「探索的テストをもっと知りたい」ということなのかもしれません。好きな人のことは、どんなことでも知りたくなるのと、きっと同じです。
「探索的テスト」をテストケースに換算してみる
わたしが行う探索的テストをテストケースに換算したら、いったいどれくらいになるのか。考えてみました。
１日にクローズするのは４チケットくらいでしょうか。そのほかに、テストしたけど問題があってクローズできないチケットや、まだストーリーとしては完了してないけど、朝会で聞いたことについてピンポイントで心配ごとがあるから、いまできてる部分だけにフォーカスして触ってみるチケットなどがあります。
それらを全部合わせて１日８チケットとしましょう。
１チケットあたり４探索的テストケースとすると、１日に３２個の探索的テストケースをまわしていることになります。
これをお読みくださっているあなたとわたしの１チケットの考え方や、テストケースの粒度はおそらく違いますので、なんのメトリクスにもなりませんが、以前あるシステム開発で、探索的テストではなく、事前にテスト設計、仕様化を経て出来上がったテストケースを使ってテストしたことがあります（以降「テストケースを使ったテスト」と記載します）。このとき、わたしは１日で２０テストケースくらいしかできなかったと記憶しているので、それと比較すると探索的テストで１日３２テストケースというのは（わたしの中では）まあまあ妥当な値だな、と思っています。
「テストケースを使ったテスト」のほうが実施できるテスト数が少ない理由
探索的テストとテストケースを使ったテストでは、それぞれのテストの性質も違いますし、そもそも同じテスト対象で比べているわけではないので、数値だけを見てあれこれ言うのもなんですが、差分の１２テストケースは何なのか。ちょっと気になります。
テストケースを理解する時間
テストケースを使ったテストの場合は、これは当たり前のことですが、まず目の前にあるテストケース（手順、期待する結果など）を読み、どのようなことを目的としたテストなのかを理解する時間、がどうしても必要です。探索的テストは、それらがすでにあたまの中にあるため、そのような時間はいりません。
探索的テストもしていた
テストケースを使ったテストをしたあと、やはりわたしはテストケースに書いてないことを、勝手に追加してテストしていたように思います。となると１テストケースにかかる時間は自ずと増えますよね。「miwaさんはテストを消化するのが遅い」と思われていたかもしれませんが、テストしているとどうしても気になることが出てきてしまう。そのまま放っておくことはできません。
「探索的テスト」をテストケースに展開してみる
いま、わたしが行っている探索的テストに「探索的テストの記録」を入れると、こんな感じになりそうです。
①チケットを読む
タイトル、概要、これまでの活動内容を、ざっと全部読んで、ああ、こんなことあったな、と頭の中を整理する。
関連するチケットがあれば、それも読む。気になるキーワードでチケットを全文検索して、ひっかかったチケットを拾い読む。これは探索的テストの最中に必要であれば、キーワードを変えて何度でも実施する。
②テストを読む
そのストーリーが「正しく作られたこと」を確かめることのできるテストが、チケットに書かれている（プログラマーが記載）ので、それを読む。
③テストを実行する
書かれているテストを忠実に実行する。
テストの正しさ（ストーリーと合っているか、テストの書き方がわかりづらくないかなど）もついでにテストする。誤りや不足があれば、担当のプログラマーに直してもらう。
④探索的テストを実施する
③で手を動かしてテストしている最中に、次に試してみたいことが浮かび、それがあたまの中にある。それを実施する。
⑤探索的テストを記録する（想像）
④でテストしたことを、ひとつひとつ展開し記録する。
チケットに書いてあるテストとは別のセクションに追加テストとして「なにを確認することを目的としたテストなのか」「前提条件」「テストの手順や方法」「使用するテストデータ」「期待する結果」などを書き込んでいく。
以降、そのチケットの探索的テストが終わるまで、④と⑤の作業を繰り返す。
想像してみて思うこと
実際にやったわけではないので、なんとも言えませんが、記録することにより探索のための思考がその都度中断されてしまうことは確かで、これについてはかなりストレスがかかりそうです。
記録しないときと同じようなテンション、思考回路が保てるのか？こぼれ落ちてしまうテストはないのだろうか？（バグを見つけるためにテストしているので、同じような探索的テストができない＝バグを取りこぼすかもしれない、と考えてしまい、不安な気持ちになります）
もうひとつ心配なことがあります。これはわたしだけかもしれませんが、テストケースを書くのってわりと時間がかかるのですよ。テストケースだけではなく、あらゆる文章はそうだけど、あとから誰が読んでもわかるように書くことって、とても難しい。
完璧なものは書けないにしても、合格点をもらえるくらいのものは書きたい。これには罠もあって、いくらでも時間がかけられる作業は、たいてい危険です。（このブログもそうです）
テストケースを書いたらそれで終わりではないですよね。その書いたテストケースを他人が読んで、わたしがやった探索的テストを再現できるのか（できそうか）を確認すると思います。数分前にも同じ探索的テストをしてるけど、きっと書いたテストケースをはじめて見るつもりで確認するんだろうな、と。そして、テストを書いてるときや、その書いたテストを確認する最中にも、わたしは新しいテストを思いつくのだろうな、と。
「探索的テスト」を記録することの目的とは
さて、１探索的テストケースを記録して記録したものを確認するのに１５分かかるとすると、単純計算で１日にできるのは１６探索的テストケースになります。記録しないときと比べて半減ですね。
組織やチームの中で、記録したテストケースを使って達成したい「何か」があり、探索的テストを半減してでもやる価値があると判断されたのなら、それもありなのかもしれません。
「探索的テスト」の目的とは
はじめにも書いたように、わたしたちのチームでは、探索的テストを記録することは求められていないし、どちらかというと、既にあるテストケースではなく「チームやテスト対象の今の状態」に応じた、誰もまだやったことのない「未知のテスト」を求められているように思います。それは、探索的テストを含む「テスト」で「未知のバグを見つける」ということを目的にしているから、とも言えます。
探索的テストは「その人にしかできない特別なテスト」だからこそ価値がある、とわたしは思っていますが、一方で「その人にしかできない」ことがデメリットのように語られてしまうこともあります。属人性というものですね。
わたしたちのチームでは、テスターがどのようなテストをしているのか、どこを心配しているかは、ふだんから話してますし、プログラマーもテスターも同じ場所で作業しているので、やってることが全部丸見えです。隣に座っているテスターがどんなテストをするのか見ていたり、見られたり、一緒にテストすることもあります。
「miwaさんならこういうテストをしてくるはずだ」とプログラマーが予想することもあるらしく、わたしのあたまの中にしか存在しないと思っていた探索的テストもチラチラ見えるものなんだなあと感じています。
おわりに
属人性によることのデメリットも、わからないわけでもないのです。探索的テストに関わらず、良いテストや考え方は、より多くの人に知ってもらいたいし、活かしたいですよね。
今回は、探索的テストを（厳密に）記録することを想像して書いてみましたが、テストチャーター（のようなもの）を使い、探索的テストをチームで共有したことがあり、これもなかなか面白かったので、次回はこれについてお話ししようかと思っています。
