第295回： 「ALTAのテキストをつくろう」50 （探索的テスト 後編）
◀前の記事へ 次の記事へ▶︎
≡ はじめに
前回は、「3. テスト技法」の「3.3 経験ベースのテスト技法」の「3.3.3 探索的テスト」の定義等について書きました。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「3.3 経験ベースのテスト技法」の「3.3.3 探索的テスト」の残り（カバレッジ、検出できる欠陥の種類）と「探索的テストのはじめかた」（実践）について書きます。
なお、キャッチイメージが「Hop on-Hop offバス」なのは、探索的テストツアーつながりです。
≡ 前回の復習
以下は前回出題したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果、選択肢1の「テストセッションごとにテスト結果をとりまとめると良い」が82.9%と最も多く、正解も1です。
前回のnoteでわかってほしかったことは、「テストセッションごとにテスト結果をとりまとめると良い」が全てですので、高い正解率で良かったなと思います。正答率と実施率は違うかもしれませんが、知らないことは実施できないことから考えて、素直にうれしいです。
実は、この話題は大事なことと考えていますので、今回の後半の「探索的テストのはじめかた」にも書きます。
前回の復習は以上として、今回のnoteのテーマに移ります。
≡ 探索的テストのカバレッジ
JSTQBのALTAシラバスの該当箇所の全文を引用します。
テストチャーターは、特定のタスク、目的、および成果物のために設計することができる。その後、それらの基準を達成するために、探索的テストセッションを計画する。チャーターはまた、テスト工数をどこに集中させるか、テストセッションの範囲内および範囲外はどこか、計画したテストを完了するためにどの程度リソースを投入すべきかも識別することもできる。テストセッションでは、特定の欠陥タイプやその他の潜在的な問題点に焦点を当て、スクリプトテストの形式にとらわれずに対処することができる。
色々書いてありますが、「探索的テストのカバレッジはテストチャーターで決まる（測る）」ということです。
テストチャーターのチャーターは「チャーター便」の“charter”と同じなのですが、「貸し切り」（借り切り？）と同じと言われてもピンときませんよね。
charterの語源は「紙切れ」だそうです。
そして、同じ語源から「海図（chart）」や「カード（card）」という単語も生まれたようです。また、
紙→紙に書くもの→“THE GREAT CHARTER“「大憲章」と派生したとか。
「紙＋印」で契約書になりますから、そういった概念（「紙切れにメモした約束」っぽい何か……という概念）でテストチャーターをとらえると良いと思います。
テストチャーターについては後半の「探索的テストのはじめかた」で具体例を示しますが、ここでは前回コピペした用語集を再コピペします。
テストセッションは前回の問題にもでてきましたが、「探索的テストをタイムボックスで、＝例えば30分間、実施しましょう」といったときの、時間で区切られたテストのことです。
用語集では、「1つのチャーター」は「1つのセッション」としています。
そうとは限らないんじゃないかなとも思うけれど、基本（もしくは推奨）は、「1セッションで1チャーター」なのかもしれません。
※ 用語集では、テストチャーターがチャータとなって、テストと末尾の長音記号が抜けていることがあります。用語をデーターベース化した結果の副作用（全体の用語の統一がしにくくなったから）かな。
≡ 探索的テストで検出できる欠陥の種類
JSTQBのALTAシラバスの該当箇所の全文を引用します。
探索的テストで見つかる典型的な欠陥には、スクリプトによる機能適合性テストで見逃されたシナリオベースの問題、機能境界間に存在する問題、およびワークフロー関連の問題がある。性能問題やセキュリティ問題が、探索的テストで見つかることもある。
バシッと書いてありませんが、「非機能の欠陥」は探索的テストの検出対象外（＝見つかることもある）と考えて、別途実施するのが基本です。
≡ 探索的テストのはじめかた
「探索的テストのはじめかた」はJSTQBのALTAシラバスにはありません。
ただ、ALTAの「学習の目的」では、探索的テストはK3（適用）となっています。
K3ということは、実践できるようになることが求められています。
そこで、試験にはでないかもしれませんが、どうやって探索的テストを実施するのかについて、初心者向けに書きます。
というのは、アジャイル開発にアサインされてしまったテスターは、周りの人たちから「テストエンジニアなんだから探索的テストができるに違いない」と思われて、探索的テストのしかたを教えてくれないことがあるかもしれないと思ったからです。
また、「探索的テスト」でググってみたのですが、「自由にやっていいよ」としか書いていないサイトがいくつかありました。自由と言われるだけでは、かえって初心者は途方にくれるのでは？と思いました。
探索的テストは特に厳密な手順が決まっているわけではありません。したがって「自由にやっていいよ」は正しい説明ですが、手が止まってしまう言葉でもあります。
泳ぎ方を知らないのにいきなり海へ突き落されて、「自由に泳いで」と言われても溺れてしまいますよね。😇
実は、YouTubeの「テスターちゃんチャンネル」に何本か、探索的テストの解説動画があります。
それらは、松谷さんのエキスパートさが遺憾なく発揮されている実践的な探索的テストの動画ですので、視聴されることを強くお勧めします。
説明が分かりやすく、テンポよく進む動画です。何回か探索的テストを経験した後に見ると最高なものと思いますが、こちらにも、自由度が高い表現のところが少しあります。
そこで、本当のまっさらな初心者に対して、まずは、こうしてみるといいよという「探索的テストのはじめかた」について書こうと思いました。
ググれば、根本さんや中岫さんの素晴らしい資料もありますし、カズさんのウェブサイトには何年も前から素晴らしい解説や翻訳があります。
ですから、以下はとりあえずの初めての人向けの方法です。何回かやってみて、もっと深く知りたくなったら上に書いたブログ等を探してくださいね。
■ 準備
探索的テストを始めるにあたり、「テストチャーター」を準備する必要があります。テストチャーター（test charter）とは、「テストセッションのゴールや目的を記述したドキュメント。」（ISTQB用語集より）のことです。
テストチャーターは、複数の人が探索的テストを同時に行ったときに、「同じ所ばかりが同じ観点でテストされないようにする」ための指示が書かれたカードのようなものです。
具体的には以下の形式でカードをつくります。（断言していますが、色々な書き方で良いです。実際のところ、様々な書き方が提案されています。（ここでは初心者向けに決め打ちにしています））
《テストチャーター》
● テスト対象
● テスト方法
● 見つけたいバグ
このように「テスト対象」と「テスト方法」と「見つけたいバグ」の3つが書かれたカードがテストチャーターです。超ハイレベルテストケースと言っても良いです。
このカードを何枚も用意することが「探索的テストの準備」です。
テスト対象は、探索する場所が重ならないようにするために書きます。
ソフトウェアのバグは動かないので、同じ場所を同じ方法で探索するのは1度だけでかまいません。
仮に、探索対象が、家出したネコの場合、ネコは１か所に留まっていませんので、探し終えたところにネコがやってこない探し方の工夫が必要です。
余談ですが、第二次世界大戦のときには、潜水艦をどうやって見つけて攻撃するかの研究がされました。潜水艦は移動しますから探すことが難しいです（水深の違いもありますし）。
詳しくは探索理論の本に書いてあるのですが、探索理論そのものがちょっと難しいです。
テスト方法には、後に述べるツアー名を書きます。たとえば「スーパーモデルツアー」と書きます。
なんじゃそれ？という感じだと思いますが、後に出てくるツアーのところを読むと、“ははーん”と分かります。
見つけたいバグには、「こんなバグを見つけてほしい」というときの「こんなバグ」を書きます。テスト方法によって、見つかるバグのタイプは絞り込まれますので書かなくても分かると言えばわかるのですが、初心者にとっては、探すもののイメージが湧いているほうが、目がそこに行くことにつながり、バグの見落とし防止につながります。
それでは、JaSST'18 Tokyoの「やってみよう！探索的テスト」の20ページからチャーターの例を一つ引用します。
《テストチャーター》
● テスト対象： リモートクライアント
● テスト方法： キーボードのみを使って操作する
● 見つけたいバグ： Windows特有の操作に関連する 不正動作
テスト方法がツアー名ではありませんが、このように、テスト方法にはテストで使用する資源について書くこともあります。
ツアー名で書くとしたら「知的ツアー」かな。（ツアー名は次に出てきます）
ところで、初心者がテストチャーターをつくれるのか？という疑問が湧いたかもしれません。
先輩につくってもらうのが良いですが、「テスト対象」と「テスト方法」までは機能を抜き出して、4つのツアーから１つを選ぶだけですので、なんとかなると思います。ツアーの選択に迷ったらランドマークツアーを選んでください。
見つけたいバグは参考情報ですので、無理して書かなくても大丈夫です。
つくったテストチャーターは、探索的テストを実施する人たちに分配します。タスクかんばんを使っているならテストチャーターを付箋紙に書いてタスクかんばんに貼って、やりたいカードをテスター本人に選んでもらうのも良い方法です。
■ 実施
実施前に、1つのテストチャーターを実行する時間を決めます。まずは、30分間（のタイムボックス）がよいでしょう。
そして、テストチャーターの指示にしたがってテストを実行します。
具体的には、テストチャーターに書かれているテスト対象に対して、テスト方法（ツアー）を実行し、見つけたいバグを探します。
で、何度も出てきた「ツアー」ですが、以下の4つのツアーから選んでください。
ランドマークツアー： 重要な部分 (ランドマーク) をテストする
FedExツアー： データ（FedExの荷物を連想）の流れをテストする
スーパーモデルツアー： ユーザー インターフェイスのみをテストする
知的ツアー： テスト対象にとって最も難しく厳しい条件をテストする?
このやり方になれてきたら、テストチャーターのテスト方法を無視して、1から4を同時に行ったり、他のツアー（ツアーは下記のように全23種類あります）を試してみても構いませんが、まずは、テストチャーターにある1つの方法に集中するほうが良いです。
補足として、「ツアー」が役にたつ理由について説明します。
探索的テストを実施するときに自分を観光客に喩えて観光ツアーを選んで観光する（＝テストを進める）方法が「ツアーを選ぶこのやり方」です。
旅行に行ったときのことを想像してみてください。
何も知らない街に旅したときに観光ツアー（キャッチイメージのようなバスツアー）を利用すればお手軽に、短時間でそれぞれのツアーの特色を堪能できます。
それは、探索的テストでも同様です。
ツアーを選択する比喩（メタファー）で行っていることは、探索的テストに特定の探索テーマと探索の方向性を与えることに他なりません。
探索テーマとは、言い換えれば「テストのアイデア」です。テストのアイデアを初心者に出せと求めても無理なので、James Whittakerさんは、観光ツアーのメタファーでそれを伝えています。
テストの初心者が、それを利用しない手はありません。
■ 確認
前回の問題のとおり、「テストセッションごとにテスト結果をとりまとめると良い」は初心者であっても、というより初心者は絶対にやる方が良いです。主に探索的テストを並行して実施したメンバーが集まって行いますが、そうでない人も呼んで「テスト セッション中に経験したこと」について話すことが有効です。
開発者を呼んだら、ポロっと「○○のところ、どうだった？」と聞いてくるかもしれません。聞き逃さずに、次のテストセッションで○○のところをテストしましょう。
≡ ツアーについて
上記のツアーですが、有名な『Exploratory Software Testing』という本に書いてあります。探索的テストのバイブル的な本です。
そこには、6つの地区と、23のツアーが書いてあります。以下にさらっとまとめますが、まずは、上記の4つのツアー（探索先）でいいです。
上述した4つのツアーのうち3つが「ビジネス地区」のツアーであることに注意してください。実際の観光ツアーではおそらく人気がないビジネス地区プランだと思うのですが探索的テストでは重要です。
まずは、ビジネスに支障があるバグを短時間で効率的に探索するのです。
そして、残りの一つは「観光地区」のUIツアー。
※ バグの検出数を増やしたいだけなら別の地区のツアーの方が増えるのですが、テストの価値は見つけたバグの数ではありませんから。
価値あるソフトウェアになっているかどうかを確認することのほうが大切だから。
4つのツアーだけで良いですが、以下のリストを読むことで「こういうことをするとバグが見つかるのか」とわかります（バグを見つけるアイデアの引き出しが増えます）ので、テストを初めて間もない人には参考になると思います。テストのエキスパートがみたら、「そうそう。やるよね」って感じだと思います。
※ 太字は、初心者におすすめの4つのツアーです。
① The Business District：ビジネス地区
・ The Guidebook Tour： ユーザーマニュアルをなぞる
・ The Money Tour： お金を払ってまで欲しい機能が載っている宣伝チラシをなぞる
・ The Landmark Tour： 使用頻度が高い重要な機能を巡る
・ The Intellectual Tour： 厳しい条件でテストする
・ The FedEx Tour： データの保存・処理の様子を追跡する
・ The After-Hours Tour： 金銭、保守・メンテナンスの観点で探索する
・ The Garbage Collector’s Tour： 最短経路
② The Historical District：歴史地区
・ The Bad-Neighborhood Tour： 前に良くバグったところを探索する
・ The Museum Tour： レガシーコード（テストがない古いコード）
・ The Prior Version Tour： 以前のバージョンで実行したテスト
③ The Entertainment District：エンターテイメント地区
・ The Supporting Actor Tour： 助演男優（メインに近いサブ機能）
・ The Back Alley Tour： 使用頻度の低い機能（ランドマークの逆）
・ The All-Nighter Tour： 夜間もずっと動かす
④ The Tourist District：観光地区
・ The Lonely Businessman Tour： 手数をできるだけ増やす
・ The Supermodel Tour： UIのみに着目する
・ The TOGOF Tour： Test One Get One Free (TOGOF)。同時実行
・ The Scottish Pub Tour： 見つけにくいシステム領域
・ The Collector’s Tour： システムからの出力の全てを集める
⑤ The Hotel District：ホテル地区
・ The Rained-Out Tour： 操作の開始直後に停止
・ The Couch Potato Tour： 空白の入力など、できるだけ何もしない脱力系テスト
⑥ The Seedy District：怪しげな地区
・ The Saboteur： 実行中のモジュールが使用する資源を横取りしていじめる
・ The Antisocial Tour： 不正なデータや予期しないデータを入力していじめる
・ The Obsessive-Compulsive Tour： 同じアクションを繰り返す
≡ JSTQB ALTA試験対策
いつものことですが、まずは、「学習の目的」を確認します。
TA-3.3.2 （K3）与えられたシナリオから探索的テストを識別する。
「与えられたシナリオ」とは、例えばユーザーストーリーのことです。
K3ですので、知識だけではなく適用できる（探索的テストを実施できる）能力が求められます。（K2：理解、K3：適用、K4：分析）
《問題》
探索的テストを補完するために探索的テストと分けて実施したほうが良いテストはどれか。
1. シナリオテスト
2. 非機能のテスト
3. ユーザーインターフェイスのテスト
4. エラー推測テスト
答えは次回に書きます。
≡ おわりに
今回は、「探索的テスト」の実践がテーマでした。
上に長々とツアーの話を書いたのは、それがテストに役立つからです。テストのエキスパートと呼ばれる人の多くはこういうツアーをしていると思います。
ところで、私自身、「探索的テストはテストのエキスパートが実施して初めて効果が出るテストです」と何度も言ってきました。
それは間違ってはいないと思うけど、エキスパートでなくてもバグは見つかりますし、なにより、初心者にテストの楽しさを実感してもらうために探索的テストを実施してもらうことはとても意味あることだと思うようになりました。
次回は、「3.3.4 欠陥ベースのテスト技法」です。
この記事が気に入ったらサポートをしてみませんか？