115.テスターの一日 その⑥
探索的テスト
作者はテスト経験のほとんどがテスト部隊で、探索的テストも基本的にはチームプレイでやることのほうが多かったです。
探索的テストの全体設計をする人がいて、その人の指揮に合わせて進めるという形。
探索的テストをチームプレイで行うときはセッションベースドの探索的テストが管理がしやすく進めやすいです。
デメリットとして、指揮する人がテスト全体の状況が見えていない、状況から次の打ち手を考えられないと明後日の方向に連れていかれます。
無駄な行動をすることになったりするので注意が必要です。
セッションベースドの探索的テスト
セッションベースドの探索的テストは時間で区切られたセッション、そのセッションでのミッション（目的）を設定して行う探索的テストです。
1回のセッションが終わったらデブリーフィング――終了後の相談を行って、次のセッションでの方針を決めます。
なので「学習→設計→実行→FBから次の行動を決める」という探索的テストの行動にさらに大きな枠「1回のセッションの実行→FBから次のセッションの方針を決める」のサイクルがあるわけです。
作者は1回のセッション時間は40分で設定していました。
よく理由を聞かれますが、web/appの現場の経験上です。
30分だと短いのですよ。やりたいことができずに終わったりします。
1時間だと飽きちゃうメンバー、同じことを繰り返しているメンバーが増えてきます。
その辺を見ながら調整をしていったら40分に落ち着いたといったところです。
この時間も、探索する規模によっては短くしたり長くしたり調整は入ります。
メンバーの得意不得意によって指示を変える
これは通常のマネジメントでも同じですね。
探索的テストがめっちゃ得意な人、好きな人がよくいます（作者も）
目的がバグ出しなら、下手に道筋を決めるよりも好きにやってもらった方がバグが出ます。
戦略があって何かを狙い撃ちしたいならチャーターで縛った方がよさそうです。
この辺はやりたいこと（目的）次第です。
新人さんの場合は「さぁやれ！」と放り出されても自由すぎて動けなくなることが多いです。
なのでテストチャーター（道しるべ）を用意してあげると、やることがわかりやすくなって動きやすくなります。
戦術っぽい話を思いついたままに書いてみる
このマンガの続きで、例えば1回目のセッションで特に方針を変える必要がない場合（バグ出し）の指示はきっとこうなります。
「きゅんちゃんはC,D,E機能をさっきと同じやり方で進行」
「ウサコはA,B機能を自由に進行」
この場合、機能の規模によりけりですがきゅんちゃんが3機能を見るのは40分だとつらいといったこともありそうです。
そうなると、きゅんちゃんの探索範囲は減らして次のセッションに持ち越した方がよさそうです。
あとバグ出し目的の探索的テストであれば、AgileTestingNightでこんなのも出しました。
https://www.slideshare.net/mineomatsuya/agile-151228975
A,B,C,Dの4つの機能と、メンバーがXさんYさんが居る場合、それぞれの機能をスライドしながら探索的テストです。
4回のセッションで1機能につき2名の探索的テストが通ります。
バグ出し目的の場合は、一つの機能ややることを一人だけに探索的テストを任せることはほぼなく、二名の目が通るようにはしていました。
理由は探索的テストはその人の力量で結果が変わるため、一人の目が通ったからといって、別の人が見たら気づかなかった問題が出てくることもあったからです。
スモークテスト目的などの時はまた戦術は変わってきますので注意です。
同じやり方ばかりでやるのではなく、目的によってやり方は柔軟に変えましょう。そうしないと全滅します。
「バグ登録はいつやればいいの」問題
セッションベースドをやっていると「バグ登録はいつやればいいの」問題が出てきます。
時間で縛っていますからね。
ここの作者としての返答としては「セッション完了後」です。
バグ登録時間は、作者が経験してきたwebやapp系では新人さんは15分、慣れてきた人で10分くらいでした。
それがセッション中に発生したらやりたいことがほとんどできなくなります。
なのでセッションが終わってからまとめて登録のほうがよいです。
あとバグがたくさん出た場合。
自分が見つけたバグは自分で登録したい！と思う気持ちはわかりますが、みんなで手分けして登録するのが早いです。
「探索的テストで出したバグは再現が…」問題
ゴッドハンドさんがたまにいます。
バグをいっぱい出してくれるので最高に嬉しいのです。
だがしかし。
「バグが匂ったので触ってみたらなんかバグ出ました！」
と、天才的な発言が返ってきてリーダーは頭を抱えるわけですね。
探索的テストはテスト設計、テスト手順が頭の中にあるので取り出せない場合があります。
解決法。
web系、App系の場合は画面録画しておけばいいです。
「探索的テストのログを取りたい」問題
ログを残す必要がある場合、作者の方法としては「マインドマップ」を使用します。
作者がただ何でもマインドマップを使うだけですけれどｗ
マインドマップで、どこで何をしたかをサラッと書きながら進めます。
バグが出たときはマインドマップにキャプチャと、何があったかサラッとかきます。
デブリーフィングの時間になったらそれを参照したり、何をやったか見せたいときはそのマインドマップを提出します。
先述した「録画」もログに使えそうですが、ログとするには見返すのがかなりつらいです。
（バグ再現確認にはいいんですけどね）
ただ、探索的テストは頭の中で「学習→設計→実行→分析」のサイクルが回っているので、記載でそのサイクルが遮られると……テンションが下がります！
探索的テストの時は「ノリ」とか「テンション」はかなり重要だったりするのですよ……。説明ができないけど。
1分でわかるテスターちゃんができるまで！
1分でわかるテスターちゃんができるまで！#manga #タイムラプス #マンガができるまで pic.twitter.com/ZuBs2DbfmI
— Matsu(まつ)@Testerchan (@mty_mno) 2021年10月3日
