Explore It! を 地図にする

https://wingarc1st-spqi.connpass.com/event/404025/

Transcript

1. Explore It! を 地図にする Agile Testing Night #31 ｜ E x p l o r e I t ! 翻訳版出版記念 ｜ 2 0 2 6 . 0 9 . 2 9 13章を1枚ずつ絵にして、テストプロセス・V字モデル・ テストピラミッド・4象限に置いてみた 伊藤 潤平 @jp_110 ウイングアーク1st ／ 翻訳チーム・スクラムフェス新潟
2. 今日やってみること 章ごとに完結している本だから、 いろいろな「地図」に置ける 1 13章を、13枚の絵にする 2 いつもの地図に置いてみる 3 重ねて、見えてきたことを話す Explore It! 各章で著者がいちばん言いたいことを、図とひとことに絞ります。 テストプロセス、V字モデル、テストピラミッド、アジャイルテストの4象限。現場で見慣れた図の上に章を並べま す。 どの地図に置いても、探索は一か所に収まりきりませんでした。その理由を考えます。 を地図にする ／ Agile Testing Night #31
3. 本の見取り図 3部・13章＋付録。どの章から読んでも成り立つ 第I部 基礎の確立 1 2 3 4 5 第II部 次元を追加する テストと探索について 探索をチャーターする 詳細を観察する 興味深いバリエーションを探す 結果を評価する 6 7 8 9 手順・データ・状態・環境へと、揺さぶる軸を増 やしていく。 チャーターを立て、観察し、変数を見つけ、結果 を判断する。探索の土台。 付録 A 探索的テストのスキルを見極める面接 各章末には、すぐ試せる「演習」がついています。 このあとのスライドでは、章の色を 第I部 第II部 Explore It! を地図にする ／ Agile Testing Night #31 手順と相互作用を変化させる エンティティとその関係性を探索する 状態遷移の発見 エコシステムを探索する B テストヒューリスティック・チートシート 第III部 で塗り分けます。 第III部 文脈に沿って考える 10 11 12 13 ユーザーインターフェースがない場合 の探索 既存システムの探索 要件の探索 探索を全体に統合する UIのない世界、既存システム、要件、そしてチー ム全体へ。
4. そもそも「探索的テスト」とは JSTQBの定義と、この本の定義 JSTQB Foundation Level シラバス「探索的テスト」 探索的テストは、形式的ではない（事前定義されていない）テストであり、テスト実行時に動的に 設計、実行、ログ記録、および評価をする。テスト結果を使用してコンポーネントまたはシステム についての理解を深め、さらにテストを行わなければならない領域のテストケースを作成する。 探索的テストでは、活動を体系的にするためにセッションベースドテストを使用する場合がある。 セッションベースドテストでは、探索的テストをあらかじめ決められた時間枠内で行う。テスト担 当者はテスト目的を含むテストチャーターに従ってテスト実行をする。テスト担当者はテストセッ ションシートを使用して、実行した手順や発見した事象を文書化する場合がある。 探索的テストは、仕様がほとんどなかったり、不十分であったり、テストのスケジュールに余裕が なかったりする場合に最も効果が大きい。他の形式的なテスト技法を補完する場合にも効果が大き い。 探索的テストは対処的テスト戦略と密接に関連付けられている（5.2.2 節を参照）。探索的テスト は、他のブラックボックス、ホワイトボックス、経験ベースの技法と併用できる。 出典：JSTQB Foundation Level シラバス（4.4.2 探索的テスト） Explore It! を地図にする ／ Agile Testing Night #31 この本（ 1 章）の言い方 システムについて学ぶために、設計と実行を同 時に回し、前の実験でわかったことで次の一 手を決める。 シラバスの言葉と、本の章 動的に設計・実行・評価、理解を深める セッションベースドテスト テストチャーター 仕様がない・不十分 他の技法を補完・併用 章・5章 1章・13章 2章 11章・12章 4章・7章・8章・付録B 1
5. 13章を、13枚の絵に PART 1 左に「著者が言いたいこと」、右にそれを1枚にした絵。 1章およそ1分で駆け抜けます。
6. 01 第 I 部 基礎の確立 テストと探索について チェック ＝ 期待どおりかを確かめる網 「ほかにリスクは？」に答える ! 著者が言いたいこと 穴 チェックしただけでは、テストは終わらない。 網の外を探索して、はじめて「テスト完了」。 テストとは、リスクに関する問いに答えるための実験 問いは2つ。想定どおり動くか（チェック）と、ほかにリスクはないか （探索） 設計と実行を同時に回し、学んだことで次の一手の舵を切る チェック Explore It! 探索 SBTM セッション を地図にする ／ Agile Testing Night #31 探索 ＝ 網の外へ ! ! SBTM ： タイムボックスの セッションで進める 設計 舵取り 同時に回す 学習 実行
7. 02 探索をチャーターする 第 I 部 基礎の確立 著者が言いたいこと 探索には「使命書（チャーター）」を持って出 かける。どこへ、何を持って、何を見つけに行 くのか。 ジェファーソンがルイスとクラークに渡した使命書がお手本 型は ターゲット／リソース／情報。細かすぎず、ざっくりすぎず 種は要件の会話、関係者の疑問、バグ票、そして最悪の事態の想像 チャーター Explore It! 悪夢の見出しゲーム 多重投票 を地図にする ／ Agile Testing Night #31 チャーター ターゲット リソース 情報 Explore with to discover プロフィール編集機能 攻撃を模した入力データ セキュリティ上の弱点 ちょうどいい ＝ 探索の「きっかけ」 細かすぎる → ただのテストケース ざっくりすぎる → いつまでも終わらない 種：要件の会話 / 関係者の疑問 / コード・バグ票 / 悪夢の見出し
8. 03 詳細を観察する 第 I 部 基礎の確立 見ようとしていないものは見えない （ムーンウォークする熊・見えないゴリラ） 画面 著者が言いたいこと 人は、見ようとしていないものを見落とす。視 点を変え続け、水面の下をのぞく。 注意を一点に絞るほど、予期せぬものは見えなくなる 「完了した？」で止めず、「本当に使える？」まで問いを深くする ログ・コンソール・OSのモニタで舞台裏を見る。五感も使う 非注意性盲目 Explore It! テスト容易性 ログ を地図にする ／ Agile Testing Night #31 ログ ファイル 表面の問い 「インストール は完了した？」 水面 コンソール ネットワーク メモリ・CPU データベース 深い問い 「入れたソフトは 本当に使える？」
9. 04 変数の見つけどころ 第 I 部 基礎の確立 興味深いバリエーションを探す 著者が言いたいこと 変数はどこにでもある。「こんなもんでしょう」 で満足せず、面白い変数を狙う。 変数には、明らかなもの・とらえにくいもの・間接的なものがある 大事故の陰には、見落とされた変数（入力の速さ、速度、ファイル数） 変数の中にさらに変数がある。数・位置・形式・サイズ・時間を揺ら す 0 ・1・複数 Explore It! 先頭・途中・最後 一部・なし・すべて を地図にする ／ Agile Testing Night #31 明らかな変数 入力欄・引数・設定 とらえにくい変数 URLの値・隠し設定・入力の対称性 間接的な変数 同時ログイン数 起動した回数 数えられるもの 位置 場所 地理 フォーマット サイズ 深さ タイミング 入力方法
10. 05 結果を評価する 第 I 部 基礎の確立 著者が言いたいこと 正解がわからなくても、判断はできる。守るべ きルールと拠り所を先に見つけておく。 どんな条件でも破ってはいけない Never/Always を関係者と洗い出す 拠り所はソフト自身の一貫性、標準規格、比べられる他製品 正確に計算できないなら、範囲・分布・逆算で近似して確かめる Never/Always Explore It! オラクル問題 有用な近似 を地図にする ／ Agile Testing Night #31 結果：12.8 m/s これは正しい？ Never / Always 別の拠り所 ALWAYS 勘定は常に合う NEVER 同じ買い物で 二度請求しない ・ソフト自身の一貫性 ・標準規格 ・比較できる他製品 関係者と洗い出す 仕様書がなくても 近似する 妥当な範囲に入る？ 0 ・分布や傾向を見る ・逆算（√x → x²） ・極端な条件で拡大 20
11. 06 手順と相互作用を変化させる 第 I I 部 次元を追加する 著者が言いたいこと ユーザーはお行儀よく使ってくれない。まず自 分の「いつもの操作」を崩す。 名詞と動詞をランダムに組み合わせ、ふだん通らない手順をつくる 閉じる・戻る・入力・保存・取り消しを「すべての方法」で試す ペルソナになりきる。極端なペルソナで即興劇のように遊ぶ 名詞と動詞 Explore It! ペルソナ 極端なペルソナ を地図にする ／ Agile Testing Night #31 名詞（モノ） 動詞（アクション） メッセージ 送信する 下書き 3 1 添付 連絡先 編集する 転送する 2 フォルダー ランダムに引いて、その順に操作する 意味不明な組み合わせほど発想が広がる 削除する 移動する
12. 07 第 I I 部 次元を追加する エンティティとその 関係性を探索する 著者が言いたいこと システムはエンティティ（名詞）とその関係で できている。ER図で地図を描き、CRUDで揺 さぶる。 エンティティ＝自分で作れるもの。セッションのような見えにくいも のも探す 「〜を持っている」と言えたら関係。ER図にスケッチして全体をつか む 各エンティティを作成・表示・更新・削除（CRUD）してみる。値や子 の数（0・1・複数）を変え、他の画面での見え方まで追う CRUD ER 図 Explore It! データを追う を地図にする ／ Agile Testing Night #31 サプライヤー 名前 連絡先 「〜を持っている」は関係のサイン 1 C 作成 N 仕入れ条件 R 表示 N 1 U 更新 アイテム 品番 説明・価格 D 削除 × 属性の値を変える × 子の数を 0・1・複数に データを追う 検索結果 レポート サプライヤーを消したら、そのアイテムはどう見える？ 最近使った一覧
13. 08 第 I I 部 次元を追加する 状態遷移の発見 割り込むなら「一瞬の状態」 ログアウト済み ログイン 認証OK 認証中 ログイン済み 著者が言いたいこと 再現しにくいバグは「脆弱性の窓」に潜む。状 態遷移モデルで、その窓を見つける。 「〜している間は」と言えたら、それは状態 イベントはユーザー操作だけでなく、外部・システム内部・時間から も来る すべての道筋・割り込み・表にしたときの空欄を狙う 状態遷移図 Explore It! 割り込み 状態遷移表 を地図にする ／ Agile Testing Night #31 ログアウト ／ タイムアウト ログアウト済み 認証中 ログイン済み ログイン キャンセル 認証中 — ??? ??? ??? — ログアウト済み ??? ??? 表にすると、まだ誰も試していない遷移「???」が見える 時間切れ
14. 09 エコシステムを探索する 第 I I 部 次元を追加する 著者が言いたいこと ソフトウェアは単独では動いていない。依存の 地図を描き、「What If?(もしも?)」を実際に試 す。 インターフェース・外部依存・内部の構成を1枚の図にする 手を出せる場所はすべて信頼境界。あえて信頼を裏切ってみる 接続が切れたら、応答がなかったら、ファイルが壊れていたら？ エコシステム図 Explore It! 信頼境界 What If? を地図にする ／ Agile Testing Night #31 信頼境界 Webアプリ 画面 アプリ本体 利用者 切れたら？ 管理画面 管理者 DB 壊れたら？ 画像ファイル ロックされたら？ What If?(もしも?) を地図の上で試す 決済 ゲートウェイ
15. 10 第 I I I 部 文脈に沿って考える ユーザーインターフェ ースがない場合の探索 著者が言いたいこと 探索は画面のためだけのものでも、テスターだ けのものでもない。 API：空文字・null・長文を渡すだけで性能の問題が見えた 言語そのもの：JavaScript の sort は数値を文字として並べる Webサービスやサーバーも、回数・サイズ・頻度・タイミングで探れ る API サービス Web Explore It! どの層でも を地図にする ／ Agile Testing Night #31 GUI 画面 Webサービス・サーバー リクエストの回数・サイズ・頻度 API・関数 引数の中身を変えてみる 言語・ライブラリ 基盤の「癖」を知る どの層にも 変えられるものがある similarity("", "") → 1（完全一致？） similarity(null, null) → 例外で停止 [7, 3, 11].sort() → 11,3,7
16. 11 既存システムの探索 第 I I I 部 文脈に沿って考える 著者が言いたいこと 誰も全体を知らないシステムは、偵察から始め て、みんなで地図を作る。 偵察セッションで、何をして何につながり何を変えられるかをつかむ 発見を共有すると学習が速い。関係者には文脈と既知を添えて聞く 再現しないバグも、関わる変数をすべて押さえれば再現できる 偵察セッション Explore It! インタビュー 再現性なし を地図にする ／ Agile Testing Night #31 ? 偵察セッション 入力 出力 ? ? ? ? 連携先 設定 エラー ? ? ? ? データ 状態 隠し口 ? ? ? ? ログ ? ? みんなで共有 → 学習が加速 関係者に聞く 文脈＋既知＋問い 再現しないバグ ＝未知の変数
17. 12 第 I I I 部 文脈に沿って考える 要件の探索 著者が言いたいこと 実装がまだなくても探索はできる。要件の段階 で「What If?(もしも?)」を問う。 要件の場に入り込む。テストを話し合えば、要件の話し合いになる コアバリューと What If? で期待をそろえ、後のスコープ論争を防ぐ 話しながらチャーターを書く。文書は入力・処理・出力・質問で読む 要件会議 Explore It! What If? アクティブリーディング を地図にする ／ Agile Testing Night #31 アクティブリーディング 入力 処理 取り込むファイル 変換のルール 監視するイベント What If?(もしも〜なら?) 出力 質問 レポート 上限を超えたら？ ログ出力 空だったら？ ここで探索する 要件 これ、何のため？ チャーターに書いておきます コードはまだない 設計 実装
18. 13 探索を全体に統合する 第 I I I 部 文脈に沿って考える 著者が言いたいこと 探索は最後のおまけではない。最初から、チー ム全員で、ずっと続ける。 規律あるチェック（TDD・CI）と熟練した探索の組み合わせが品質を 生む 探索での驚きの多さは、プロセスの網の粗さを映す鏡 やめどきは時間切れではなく、問いが尽き、学びが止まったとき ペア探索 Explore It! 見積もり 報告 を地図にする ／ Agile Testing Night #31 この本の姿 よくある姿 最後にちょっとだけ 要件 設計 実装 報告は3点で 1. 何を探索したか 2. 何を見つけたか 3. まだ見ていないのはどこか リリース 誰が？ TE Dev/PdM BA チーム全員・ペアで
19. 付録 付録A は「探索できる人」の見極め方、 付録B はヒューリスティック集 探索的テストのスキルを見極める面接 A 面接そのものを、候補者と一緒にやる探索セッションにす る。見るのはバグの数ではなく、問いの立て方と伝え方。 1 2 3 一緒に探索 面接官が操作し、候補者が指示する ふりかえり わかったこと、驚いたことを話してもらう 舵取り 別のチャーターを渡し、次に何を調べたいかを聞く Explore It! を地図にする ／ Agile Testing Night #31 B テストヒューリスティック・チートシート 数と量 位置と構造 手順と状態 データ 判断とモデル 環境と Web ゼロ 0・1・複数 少なすぎる 多すぎる 一部・なし・すべて ゴルディロックス 割り込み 逆にする ズームイン Never/Always ルール 有用な近似 抽象化する モデルを変えてみる 先頭・途中・最後 すべてを一箇所に集める すべてを分散させる CRUD データを追う データフォーマットルールに違反する リソース不足にする 戻る・進む・履歴 ブックマークも試す グループ分けは私の勝手な解釈です。本では一般（20種）と Web 向け（2種）に分かれています。
20. 13 枚を 1 枚に チェック ＝ 期待どおりかを確かめる網 探索 ＝ 網の外へ チャーター ! ターゲット 「ほかにリスクは？」に答える 穴 画面 攻撃を模した入力データ with ログ コンソール ファイル ネットワーク セキュリティ上の弱点 to discover ! SBTM 舵取り ： タイムボックスの セッションで進める 1 設計 同時に回す ちょうどいい ＝ 探索の「きっかけ」 実行 細かすぎる → ただのテストケース 学習 名詞（モノ） 動詞（アクション） メッセージ 送信する 下書き 2 サプライヤー 名前 連絡先 編集する 3 1 添付 転送する 2 連絡先 移動する 仕入れ条件 R 表示 検索結果 U 更新 レポート 7 出力 ? ? ? 入力 処理 ? 設定 エラー ? 変換のルール 連携先 ? 取り込むファイル 監視するイベント ? ? データ 状態 隠し口 ? ? ? ? ? ログ 関係者に聞く 文脈＋既知＋問い ? 再現しないバグ ＝未知の変数 既存システムの探索 ログイン ログアウト済み ログアウト済み 認証中 最近使った一覧 ログイン済み 質問 レポート 上限を超えたら？ ログ出力 空だったら？ ここで探索する 要件 8 12 4 信頼境界 認証OK Webアプリ 認証中 キャンセル 時間切れ 認証中 — ??? ??? ??? — ログアウト済み 管理画面 管理者 状態遷移の発見 要件 設計 実装 1. 何を探索したか 2. 何を見つけたか 3. まだ見ていないのはどこか 実装 13 リリース 誰が？ TE Dev/PdM BA チーム全員・ペアで 探索を全体に統合する これは正しい？ Never / Always 5 壊れたら？ ・ソフト自身の一貫性 ・標準規格 ・比較できる他製品 関係者と洗い出す 仕様書がなくても Webサービス・サーバー リクエストの回数・サイズ・頻度 決済 ゲートウェイ API・関数 画像ファイル 引数の中身を変えてみる ロックされたら？ 言語・ライブラリ What If?(もしも?) を地図の上で試す エコシステムを探索する 13枚を 並べてみると 観察する → 変数を見つける → 揺 さぶる → 判断する、の技法が 文脈（UIなし・既存・要件・チー ム）ごとに使い回されている 10 近似する 妥当な範囲に入る？ 0 20 ・分布や傾向を見る ・逆算（√x → x²） ・極端な条件で拡大 結果を評価する 画面 アプリ本体 DB 別の拠り所 ALWAYS 勘定は常に合う NEVER 同じ買い物で 二度請求しない 基盤の「癖」を知る 9 最後にちょっとだけ 結果：12.8 m/s GUI 切れたら？ 報告は3点で を地図にする ／ Agile Testing Night #31 画面 利用者 よくある姿 チャーターに書いておきます 要件の探索 ログイン済み ログイン ??? ??? 興味深いバリエーションを探 す 割り込むなら「一瞬の状態」 この本の姿 これ、何のため？ コードはまだない 設計 同時ログイン数 起動した回数 表にすると、まだ誰も試していない遷移「???」が見える What If?(もしも〜なら?) 出力 間接的な変数 ログアウト ／ タイムアウト D 削除 エンティティとその関係性を探 索する 入力 Explore It! 品番 説明・価格 アクティブリーディング 偵察セッション みんなで共有 → 学習が加速 1 サプライヤーを消したら、そのアイテムはどう見える？ 手順と相互作用を変化させる ? N URLの値・隠し設定・入力の対称性 深い問い 「入れたソフトは 本当に使える？」 詳細を観察する アイテム データを追う 意味不明な組み合わせほど発想が広がる 11 N 3 × 属性の値を変える × 子の数を 0・1・複数に ランダムに引いて、その順に操作する 6 「〜を持っている」は関係のサイン 1 C 作成 削除する フォルダー 探索をチャーターする とらえにくい変数 メモリ・CPU データベース ざっくりすぎる → いつまでも終わらない 種：要件の会話 / 関係者の疑問 / コード・バグ票 / 悪夢の見出し テストと探索について 入力欄・引数・設定 水面 ! 数えられるもの 位置 場所 地理 フォーマット サイズ 深さ タイミング 入力方法 明らかな変数 表面の問い 「インストール は完了した？」 （ムーンウォークする熊・見えないゴリラ） プロフィール編集機能 Explore リソース 情報 変数の見つけどころ 見ようとしていないものは見えない どの層にも 変えられるものがある similarity("", "") → 1（完全一致？） similarity(null, null) → 例外で停止 [7, 3, 11].sort() → 11,3,7 ユーザーインターフェースがな い場合の探索
21. いつもの地図に、置いてみる PART 2 テストプロセス ／ V字モデル ／ テストピラミッド ／ アジャイルテストの4象限 チップの色は部を表します（ I II III）。 ※置き場所は私の勝手な解釈です。
22. 地図 1 テストプロセス（ J S T Q B のテスト活動） 章をテストプロセスに置くと、重心は「テスト分析」と「テスト設計」にあった この章でやること テストと探索について 2 探索をチャーターする 3 詳細を観察する 4 興味深いバリエーションを探す 5 結果を評価する 6 手順と相互作用を変化させる 7 エンティティとその関係性を探索する 8 状態遷移の発見 9 エコシステムを探索する 10 ユーザーインターフェースがない場合の探索 11 既存システムの探索 12 要件の探索 13 探索を全体に統合する B 付録B チートシート 1 戦略・セッション 何を狙うか 見る仕掛け・観察 変数を洗い出す 結果の判断 手順を組み替える エンティティと関係 状態とイベント 依存の地図・環境 スクリプトで試す 偵察・再現・記録 要件で問う 見積もり・やめどき・報告 ヒューリスティック 重み（•＝2、◦＝1） Explore It! 計画 分析 設計 実装 実行 完了 ↔ テストのモニタリングとコントロール（全体にかかる） を地図にする ／ Agile Testing Night #31 探索的テストは「実行のテクニック」 と思われがち。 でも本の大半は、何を変えられるか（変数）と どう揺さぶるか（モデル・ヒューリスティッ ク）を見つける話。つまりテスト分析とテスト 設計です。 モニタリングとコントロールは計画から完了ま での全体にかかる活動なので、表の列からは外 しました。モニタリングとコントロール、テス ト完了を正面から扱うのは13章（見積もり・や めどき・報告）です。 • 8 14 13 4 9 3 ＝その章の主な舞台 ◦＝関わりがある
23. 地図 1 テストプロセス（つづき） テスト活動は、1回のセッションの中でぐるぐる回る よくあるイメージ：順番に1回ずつ 計画 分析 設計 実装 実行 テストのモニタリングとコントロール（全体を通して） 完了 探索では：1つのセッションの中で、何周も回る 計画 報告し、学びを残す 11 ・13章 すぐ試し、結果を判断する 3 ・5章 2 章 完了 実行 モニタリングと コントロール ＝学んだことで 舵を切る（1章） 実装 Explore It! チャーターを決める を地図にする ／ Agile Testing Night #31 分析 変数・状態・依存を見つける 設計 次の実験を思いつく 4 6 ・7・8・9章 章・付録B 見る仕掛け・スクリプトを用意 3 ・10章 1章の定義を、テストプロセスの言葉で言 い直すと。 チャーターで計画し、変数を分析し、実験を設計し、 すぐ実装・実行して、結果から学ぶ。そのすべてを見 張りながら舵を切る（モニタリングとコントロール） のが探索です。 セッションの外側には、もうひとまわり大きなループ があります。報告して学びを残し（テスト完了）、次の チャーターを決める（13章）。 だから「テスト設計が終わってから探索する」ではなく、探索の中に テスト設計がある。
24. 地図 2 V 字モデル 右側の「テスト工程」だけでなく、左側でも探索が効く 要件の探索 5 Never/Always 2 要件からチャーター 12 9 エコシステム図 8 7 要件定義 状態モデル ER図 8 受け入れテスト 基本設計 一時的な状態 本に出てくる図は、 左側の設計モデルと同じ形 詳細設計 システムテスト 単体テスト 全体を貫く章 1 10 チェック＋探索 観察 4 変数 6 手順 9 What If? 11 偵察 3 CRUD・データを追う 10 Webサービス 7 結合テスト 実装 ペルソナ 5 比較対象・規格 13 意思決定者へ報告 6 9 API・関数・言語 4 0・1・複数 チャーター 13 早く、頻繁に 2 信頼境界 ER図（7章）、状態遷移図（8章）、コンテキスト図（9章）は、V字の左側で作られる設計モデルそのもの。探索者はそれをテストのための地図として描き直し、右側で 使います。12章はさらに一歩進めて、左上の要件定義そのものを探索します。 Explore It! を地図にする ／ Agile Testing Night #31
25. 地図 3 テストピラミッド 起点はてっぺん。そこから全層を貫く「縦串」 てっぺんを起点に、UI → API → ユニットまで貫く 探索 ここが起点 UI／E2E サービス／API ユニット 1 チェック＋探索 チャーター 3 画面の観察 6 すべての操作方法 9 What If? 10 Webサービス 10 関数・言語の探索 2 4 ペルソナ 6 7 8 11 偵察 割り込み CRUD・データを追う 8 状態遷移 変数と境界 探索はピラミッドのてっぺん（雲）に描かれます。そこが起点なのは間違いありません。でも本は、そこから UI、API、関数や言語そのものまで降りていく姿を見せて います（10章）。見つけた穴は、ふさわしい層の自動チェックで塞ぎます（1章の「網」、13章のペア探索）。 Explore It! を地図にする ／ Agile Testing Night #31
26. 地図 4 アジャイルテストの 4 象限 起点は Q3。そこから4象限すべてに探索が存在する チームを支援する 面スネジビ Q2 機能テスト・例・ストーリーテスト Q3 探索的テスト・ユーザビリティ・UAT 要件の探索 5 Never/Always 13 BAとペア探索 11 例の表→自動化 チェック＋探索 2 チャーター 3 観察 4 変数 6 ペルソナ 11 偵察 1 12 Q1 ユニット・コンポーネント 面術技 Explore It! 製品を批評する 起点 Q4 性能・負荷・セキュリティ・〜性 What If?・信頼境界 8 割り込み・タイミング 5 品質特性 4 事故と変数 10 性能の兆し 9 10 API・関数・言語 13 TDD×探索 を地図にする ／ Agile Testing Night #31 探索的テストは Q3 に描かれるのが 定番。そこが起点です。 でも本を読むと、Q3 を起点に、探索はほかの 象限にも存在しています。 12章は Q2（要件を例で固める側）に、10章は Q1（コードの内側）に、9章と8章は Q4（壊れ 方・タイミング・安全性）に。
27. おまけの地図 章どうしのつながり 本の中の「起点」を探すと、4章がハブだった 1 テストと探索について 2 探索をチャーターする 3 4 5 第I部 Explore It! 6 手順と相互作用を変化さ… 10 ユーザーインターフェー… 7 エンティティとその関係… 11 既存システムの探索 8 状態遷移の発見 12 要件の探索 詳細を観察する 興味深いバリエーション… 結果を評価する 9 第II部 を地図にする ／ Agile Testing Night #31 エコシステムを探索する 13 第III部 探索を全体に統合する ピラミッドではてっぺん、4象限で は Q3 が起点でした。では、本の中 の起点は？ 本文中の「第◯章を参照」を数えると、いちば ん呼ばれるのは 4章「興味深いバリエーション を探す」（計8回）。エンティティも状態も既存 システムも要件も、最後は「何を変えられる か」に戻ってきます。 11章と12章は、第I部・第II部のヒューリスティ ックと技法をまとめて使う、集大成の章です。 円の大きさ＝ほかの章から参照された回数。線の太さも参照 回数。
28. おまけの地図 5 W 1 H 13章は、探索の5W1Hにそのまま答えている なぜ WHY 何を WHAT WHERE どこで チェックでは答えられない「ほかにリスク は？」に答えるため。正解がなくても判断で きるように。 関係者が価値を感じる情報を、チャーターで 狙いを定めて取りにいく。 画面の外側まで。依存先、API、関数、言語 そのものまで。 1 2 9 5 WHEN いつ WHO 誰が HOW 10 どうやって 要件の会話から、コードの1行目から、リリ ースまでずっと。 テスターだけでなくチーム全員。ペアで、み んなで共有しながら。 観察し、変数を見つけ、手順・データ・状態 を揺さぶる。 12 13 3 13 Explore It! を地図にする ／ Agile Testing Night #31 11 4 6 7 8
29. 地図を重ねてみると 探索は、どの地図にも「一か所」には収まらない テストプロセス 重心はテスト分析と設計。7つの 活動が1回のセッションで何周も 回る。 V 字モデル 右側の工程だけでなく、左側の要 件定義と設計の段階から効く。 テストピラミッド 起点はてっぺん。そこから UI・ API・ユニットまでを貫く縦串。 探索は、工程やテストレベルの名前ではなく 学びながら舵を切る「振る舞い」なのだと思います。 次のスライドで、なぜそう思うのかを少しだけ。 Explore It! を地図にする ／ Agile Testing Night #31 4 象限 起点は Q3。そこから Q1・Q2・ Q4 のすべてに存在する。
30. 「テスト」という名前について 探索的テストは「テスト」と名がつくけれど、 ただのテストではない よくある思い込み テストプロセス、テストタイプ、テストレベル。「テスト」と名のつくもの は、どれも品質保証活動のひとつにすぎないと思われがちです。 私の反省 〇〇テストフェーズ で、 ××テストレベル の、 △△テスト を実行 こんなふうに専門用語ばかり並べて、チームの誰も「それが何のためのテス トなのか」をわからないまま、プロジェクトを進めていたことがあります。 Explore It! を地図にする ／ Agile Testing Night #31 でも探索的テストは 工程の名前でも、テストレベルの名前でも、テストの種類でも ない どの地図に置いても、起点になって全体に広がっていた 「何のために、何を知りたいのか」をチャーターで言葉にし、 学びながら舵を切る振る舞いそのもの だから日本語版の副題は「リスクを減らす」ではなく 「プロダクトの価値と自信を高める」にしました。
31. どこから読む？ まず全員 1〜5章 探索の土台。ここだけでも持ち帰れる 画面を触る人 6章 いつもの操作を崩す データの多い業務系 7章 CRUD とデータを追う 再現しないバグに悩む人 8・11章 状態と変数で追い詰める API・バックエンドの人 9・10章 依存の地図と、画面のない探索 PdM・BA 12章 要件の段階で「What If?(もしも?)」を問う リーダー・マネージャー 13章 見積もり・やめどき・報告 『Explore It! プロダクトの価値と自信を高める 探索的テスト実践ガイド』 エリザベス・ヘンドリクソン 著 スクラムフェス新潟 訳 ／ ZEN大学出版会 kadokawa.co.jp/product/302607002898 ありがとうございました 伊藤 潤平 @jp_110