1. まつって誰？
1.1. 新人さんからわかるソフトウェアテスト解説マンガ『テスターちゃん』作者
1.1.1. https://www.amazon.co.jp/dp/4863543026
1.2. 勤め先ではQA組織所属。テストのコンサルタントのイメージ
1.3. JaSST Kyushu(ソフトウェアテストシンポジウム九州) 実行委員長
1.4. QA4AI(AI プロダクト品質保証コンソーシアム)でガイドラインのVUI領域(音声認識、自然言語理解、音声合成)担当
1.5. 会社でもプライベートでもテスト系のことをしてる変な人
2. 目次
2.1. 今回はこのような話をしていきます
2.2. セッションベースドの探索的テストとは
2.3. セッションベースドの探索的テストのメリット・デメリット
2.4. セッションベースドの探索的テストのやり方
2.5. セッションベースドの探索的テストの具体例
2.6. まとめ
3. セッションベースドの探索的テストとは
3.1. すごく乱暴に言うと「時間で区切った探索的テスト」です
3.2. これだと乱暴すぎてテスト界隈の人に怒られてしまいます
3.3. もう少し丁寧に言うと「セッションベースドマネージメントで進める探索的テスト」となります
3.4. 時間で区切って探索的テストして、その結果をもとに次の探索的テストの方針を決めて進めます
3.5. 時間で区切られた1回の探索的テストを「セッション」といいます
3.6. そのセッションの結果を分析して次どうするか決める、というようにテストをマネージメントしていくわけです
3.7. なので「セッションベースドマネージメントで進める探索的テスト」というわけですね
4. セッションベースドの探索的テストの メリット・デメリット
4.1. メリット
4.1.1. 時間で区切られているので集中力が続きやすい
4.1.1.1. 探索的テストは長々とやると集中力が途切れて何も探索できなくなります
4.1.2. 状況に合わせてテストをマネージメントできる
4.1.2.1. 前のセッションで問題を見つけたら、次はそこに集中するといったように臨機応変に動きやすくなります
4.2. デメリット
4.2.1. 管理が大変
4.2.1.1. 何を何分、としっかりと決めて進める必要があるので、普通の探索的テストよりは大変です
4.2.1.2. 探索的テストが好きすぎると「バーサーカー化」して「もっともっと！」となっていてセッションが壊れることがあります
4.2.1.3. 時間時間で管理するので、見ていた開発の人から「まつさんはトイレまで管理しているのでは」とあらぬ疑いをかけられた
4.2.2. リーダーがテストを考えられないと、みんなが明後日の方向に連れていかれる
4.2.2.1. ダメな人の「管理」が逆にテストをまずい方向に導くことがあります
5. セッションベースドの探索的テストのやり方
5.1. 流れはこんな感じです
5.1.1. 1回のセッションの時間を決める
5.1.2. そのセッションでの目的（ミッション）を決める
5.1.3. 目的に沿って探索的テストを実施する
5.1.4. そのセッションでの結果について話す
5.1.5. 次のセッションの目的を決める
5.1.6. その繰り返しです
5.2. では具体的に見ていきましょう
5.3. 1回のセッションの時間を決める
5.3.1. 一般的には45分から120分と言われています。
5.3.2. テストの目的が何かによって時間は変わってくるかと思います
5.3.3. ただ僕はweb系App系でのテストの現場では基本的には40分で行うことが多かったです。
5.3.4. なぜかと言うと
5.3.4.1. まず30分では短いです。やりたいことができずに終わります。
5.3.4.2. けど1時間だと飽きてしまうメンバーがでてきてしまいます
5.3.4.3. 単純に集中力が途切れてしまったり
5.3.4.4. 探索的テストが苦手だとやることが思い浮かばず、同じことを繰り返したりしてしまいます
5.3.4.5. ちょうどよさそうな時間を模索した結果「40分」に落ち着きました
5.3.4.6. 現場としてはテスト初心者が多い現場でしたので皆さんの現場ではこうとは限りません
5.3.4.7. 丁度良い時間を見つけてみてください
5.4. そのセッションでの目的（ミッション）を決める
5.4.1. そのセッションで何をするか決めます
5.4.2. 前回の動画で説明したテストチャーターと同じ捉え方で大丈夫です。
5.4.3. 例えば
5.4.3.1. デグレが気になるなら「バグチケットをチャーターとしてデグレを発見する」
5.4.3.2. ブラウザを縮めた状態でのUIが気になるなら「ブラウザサイズを変更してUI崩れを発見する」
5.4.3.3. などなど、状況に合わせて色々考えられます。
5.4.3.4. （僕は「～がないこと」確認は探索的テストでは基本的には設定しません。 だって「探索」ですもん。これだけで探索の姿勢が変わります）
5.4.4. 他にも前回の動画で説明した「ツアー」を使うのもいいでしょう
5.5. 目的に沿って探索的テストを実施する
5.5.1. 先ほどの目的やチャーターに合わせて探索的テストを実施します
5.5.2. おさらい
5.5.2.1. （チャーターを参考に）何を試すか, その結果どういった動きになるかイメージ（脳内設計）する
5.5.2.2. 考えたことを試す
5.5.2.3. 試してみたことから得たFeedBackから次に試すことを考える
5.5.2.4. 繰り返しながら進めていく
5.5.2.5. こんな感じでしたね
5.6. そのセッションでの結果について話す
5.6.1. 次のセッションをどうするか考えるため、話をするなどして状況把握をします
5.6.2. 話をすると「UIが……」とか「なんかモッサリしてない」などの話が出たりします
5.6.3. 時間は特に何分でもよいです。
5.6.4. チャットでちょっと聞くだけでもいいし、ボロボロなようならじっくり話し合ってもいいでしょう
5.6.5. あと僕の経験上では、バグチケット登録もこの辺の時間に手分けして行うのがよかったです
5.7. 次のセッションの目的を決める
5.7.1. さっきのセッションの結果から次のセッションでどうするか決めましょう
5.7.2. 例えば
5.7.2.1. 特に何もなければテスト範囲を変えて同じ目的で実施したり
5.7.2.2. 何か出てきたら、そこに集中してテスト実施することも考えられます
5.8. このようにセッションごとにテストをどうしていくか変えていくのが「セッションベースドの探索的テスト」です
6. セッションベースドの探索的テストの具体例
6.1. では、具体例です。想像力を働かせていきましょう
6.2. 例えば、テストケースの実施も終わり大きなバグ修正もほぼ終わったテスト後半だとしましょう
6.3. その辺の段階だと、バグ修正によるデグレが気になるころです
6.4. セッション１
6.4.1. 時間は40分
6.4.2. セッションの目的は「デグレを発見する」
6.4.3. リーダー「チャーターとして「修正済みバグチケット」を使います」
6.4.4. リーダー「Aさんはバグチケット1~10までを参考にしてください」
6.4.5. リーダー「Bさんはバグチケット11~20までを参考にしてください」
6.4.6. ～探索的テスト実施～
6.4.7. 終了後
6.4.8. Aさん「特に何もありませんでした」
6.4.9. Bさん「見てたらxxページのUIが崩れまくってますよ…safariだけっすけど」
6.4.10. リーダー「じゃあ次のセッションはxxページを中心にsafariで確認にするか」
6.4.11. リーダー「次いく前に、今見つけたバグを手分けして登録してしまいましょう」
6.5. セッション２
6.5.1. 時間は40分
6.5.2. セッションの目的は「safariでUI崩れを発見する」
6.5.3. リーダー「今回は画面仕様書をチャーターにするのと、ガーベージコレクターツアー行きますかね」
6.5.4. （ガーベージコレクターツアー：ゴミ収集車みたいにポンポンとページや機能を渡り歩くツアー）
6.5.5. リーダー「Aさんはsafariで画面仕様書参考にガーベージコレクターツアーお願いします」
6.5.6. リーダー「BさんはxxページをJSの動作も含めてsafariでガッツリ確認お願いします」
6.5.7. ～探索的テスト実施～
6.5.8. 終了後
6.5.9. Aさん「safariでUI崩れがちょいちょいでてますね。前は大丈夫だったのに。cssいじった時ですかね」
6.5.10. Bさん「JS周りの挙動は問題なかったです。UIですねやっぱり」
6.5.11. リーダー「じゃあ次もsafariかな。ガーベージコレクターツアーで軽く見ただけだしページごとにわけていこうかな」
6.5.12. リーダー「次いく前に、今見つけたバグを手分けして登録してしまいましょう」
6.6. みなさん、状況は想像できたでしょうか？
6.7. 「その作戦でいいの？」はさておき、このような感じで進めていきます
7. まとめ
7.1. セッションベースドの探索的テストとは
7.1.1. 時間で区切って探索的テストして、その結果をもとに次の探索的テストの方針を決めて進めるやり方
7.2. セッションベースドの探索的テストのメリット
7.2.1. 時間で区切られているので集中力が続きやすい
7.2.2. 状況に合わせてテストをマネージメントできる
7.3. セッションベースドの探索的テストのデメリット
7.3.1. 管理が大変
7.3.2. リーダーがテストを考えられないと、みんなが明後日の方向に連れていかれる
7.4. セッションベースドの探索的テストのやり方
7.4.1. 1回のセッションの時間を決める
7.4.2. そのセッションでの目的（ミッション）を決める
7.4.3. 目的に沿って探索的テストを実施する
7.4.4. そのセッションでの結果について話す
7.4.5. 次のセッションの目的を決める