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.2.1. テストの「方針や道しるべ」を用意して, それに沿って探索的テストをしようという方法
2.3. テストチャーター
2.3.1. テストの目的達成のための方針や目印
2.3.2. 指針を決めるもの
2.3.3. 粒度は様々
2.3.4. 細かな決まりはない
2.4. 旅行に例えると
2.4.1. 気ままに旅行するわけではなく「美味しいもの巡り」
2.4.2. 「ミシュランガイド」を参考にする
2.5. 「Explore It!」という本に書かれている例
2.5.1. チャーター「（対象）を（資源）を使って探索し、（情報）を発見する」
2.5.2. チャーター「"青森"を"ミシュランガイド"を使って探索し、"美味しいもの"を発見する」
2.6. まつの経験上からの
2.6.1. メリット
2.6.1.1. 目指す方向やガイドがあるので、「何をやればいいんだ！」になりにくい
2.6.1.2. 方針を決められるので、テストの戦略に組み込みやすい
2.6.2. デメリット
2.6.2.1. 全体を俯瞰して「テストをどう進めていけばいいか」が考えられないと方向性を決められない
2.6.2.1.1. チームの場合, リーダーが状況が見えていないと全員を明後日の方向に導く
2.6.2.2. チャーターが細かくなりすぎるとただのテストケースになる
3. 例を4つ
3.1. テスト後半、修正されたバグがたくさんあるという状況
3.1.1. 修正されたバグチケットを参考に、そのバグ発生箇所の周辺のデグレを発見しよう
3.1.2. 「Aさんはチケット1番から10番まで、Bさんはチケット11番から23番までおねがい」
3.2. テスト中盤、テストケースをしてたら特定機能にバグがたくさん出ている状況
3.2.1. X機能について、仕様書に書かれた使い方を参考にして別の使い方がないか試してみて、バグを発見しよう
3.2.2. 「仕様書に書かれてることはテストケースでカバーしているから、違う経路で使えないか考えながらAさん、Bさん試してみて」
3.3. テスト序盤、開発からプロダクトをわたされてホヤホヤの状況
3.3.1. 仕様書を参考に、主要機能が最低限動作するか探索しよう
3.3.2. 「仕様書を参考に、AさんはA~C機能、BさんはD~F機能まで探索してみて、テストケース実行が止まるような大きなバグを発見しよう」
3.4. ウチのプロダクト、キーボードのみの操作も対応してるんだよね
3.4.1. 仕様書を参考に、各ページごとにキーボード操作をして、操作不能な機能を発見する
3.4.2. 「Aさんはxxの一連のフロー、Bさんはyyの一連のフローをキーボードのみで操作してみて、動かせないところを発見しよう」
4. テストチャーターを使った探索的テストのやり方
4.1. チャーターを決める
4.2. チャーターに沿う形で探索的テストを実行する
4.2.1. チャーターを参考に、何を試すか, その結果どういった動きになるかイメージ（脳内設計）する
4.2.2. 考えたことを試す
4.2.3. 試してみたことから得たFeedBackと、チャーターを参考に、次に試すことを考える
4.2.4. 繰り返しながら進めていく
5. チャーターが思い浮かばない！ 考え方教えて
5.1. テストの状況と戦略によります
5.2. それだと回答にならないので、マツの経験では…
5.2.1. 「不安な部分はどこだ…」と己に問いかけ言語化する
5.2.2. テストケースでバグがいっぱい出ていた機能は？
5.2.2.1. テストの7原則「欠陥の偏在」
5.2.3. バグ修正が多かった機能は？
5.2.3.1. デグレ発見の目的
5.2.4. 開発するときに苦戦していた機能は？
5.2.4.1. 内部構造が複雑化しがち
5.2.5. 修正に時間がかかっていた機能は？
5.2.5.1. あと開発からのコメントに苦労話が含まれているとか
5.2.6. 新人さんが担当した部分は？
5.2.6.1. ブラックリスト方式は世間的には良しとされない
5.2.6.2. レビューしていれば大丈夫なことは多い
5.2.6.3. 仕様の勘違い/暗黙の了解部分がおかしくなってたりなど
5.2.6.4. 僕はやります。経験上やっぱりバグが出るから
5.2.7. そのプロダクト固有の特性は？
5.2.7.1. 未だにIE11対応とか
5.2.8. ユーザーがよく使う機能は？
6. ツアーという考え方を紹介
6.1. ソフトウェアの実行を旅行になぞらえて、観光客が観光地を歩き回るように探索する手法
6.2. 参照
6.2.1. Exploratory Software Testing (探索的ソフトウェア テスト)
6.2.2. 探索的テストの進め方 改訂版 - 半田技術研究所 - BOOTH
6.3. 一部紹介
6.3.1. ガイドブックツアー
6.3.1.1. ユーザーマニュアルやヘルプなどをチャーターとして探索する
6.3.2. マネーツアー
6.3.2.1. お金になる箇所、つまりアプリの売りになっている機能を探索
6.3.3. インテリツアー
6.3.3.1. ツアーガイドが答えられない質問を投げるインテリのように、アプリに厳しい質問…処理を増やすなどの探索をする
6.3.4. ゴミ拾いツアー
6.3.4.1. ごみを拾い集めるように、インターフェースやモジュールを次々実行して動作を確認する
6.3.5. 歴史的区画ツアー
6.3.5.1. 昔からあるコードで過去にバグを修正した箇所が正しく動作するか探索する
6.3.6. 悪い隣人ツアー
6.3.6.1. バグがあった近くを探索する
6.3.7. ミュージアムツアー
6.3.7.1. かなり以前から変更されていないファイルやコードをテストする
6.3.8. 前バージョンツアー
6.3.8.1. 前バージョンから変更された箇所を探索する
6.3.9. スーパーモデルツアー
6.3.9.1. あまり深入りせず、表面的な入出力インターフェイスをなぞる
6.3.10. 強迫観念ツアー
6.3.10.1. 同じ入力や同じ操作を繰り返し行う
6.3.11. 破壊行為ツアー
6.3.11.1. 不正な処理を試す。メモリを不足させる、対応していない形式のファイルを読み込ませるなど
7. まとめ
7.1. テストチャーターを使った探索的テストとは
7.1.1. テストの「方針や道しるべ」を用意して, それに沿って探索的テストをしようという方法
7.2. テストチャーター
7.2.1. テストの目的達成のための方針や目印
7.3. メリット
7.3.1. 目指す方向やガイドがあるから進めやすい
7.3.2. 方針を決められるので、テストの戦略に組み込みやすい
7.4. デメリット
7.4.1. テスト全体を俯瞰できていないと目指す方向を決められない
7.4.2. チャーターが細かくなりすぎるとただのテストケースになる