問題22：探索的テストのタスクと記録方法

問題 #22

あなたは新しいプロジェクトのテストアナリストである。要件ドキュメントは非常にハイレベル（抽象的）であり、ソフトウェアが対処すべき問題についての詳細はほとんど含まれていない。その結果、マネージャーは、このプロジェクトで使用する主要なテスト技法として「探索的テスト（exploratory testing）」を採用することを決定した。

あなたは、テストセッションの仕様化、実行、および記録のタスクを割り当てられた。

これらのタスクのために 「必要となるもの」、または「使用するもの」 を定義しているオプションはどれか？（※2つ選択してください）

a) テストセッションの結果を記録するために、テストマネージャーまたはテストリードとのデブリーフィング（報告/振り返り）セッションを使用する。
b) 欠陥管理システムに欠陥を記録するが、探索的セッションの「合格/不合格」は記録しない。結果を複製（再現）することが困難な場合があるためである。
c) エンドユーザーにアドホックなテストを実行してもらい、そのアクションを書き留めて、将来の探索的セッションとして使用する。
d) 探索的セッション中に適用するためのドメイン知識（業務知識）を調達（準備）する。
e) 結果を電子メールに記録し、その電子メールをテストマネージャーとテストリードに送信する。

正解

a) テストセッションの結果を記録するために、テストマネージャーまたはテストリードとのデブリーフィング（報告/振り返り）セッションを使用する。

d) 探索的セッション中に適用するためのドメイン知識（業務知識）を調達（準備）する。

解説

この問題は、探索的テストを体系的に管理する手法（セッションベースドテストマネジメント：SBTM）の正しい運用方法を問うています。

a) 正解。 シラバスに記載されている通り、デブリーフィング（報告/振り返り）セッションは、テスト担当者とマネージャーがテスト結果を共有し、評価・記録するための標準的な方法です。
b) 不正解。 バグだけでなく、テストチャーター（テストの目的を記した指示書）に基づいたセッション自体の「合格/不合格（あるいは達成状況）」も記録する必要があります。再現が難しいからといって記録を怠ってはいけません。
c) 不正解。 ユーザーのアクションを書き留めてテストケース（スクリプト）化するようなアプローチは、自由に学習しながらテストを設計・実行する「探索的テスト」の本来の主旨から外れます。
d) 正解。 要件が抽象的（詳細が未定義）である場合、「正しい動作とは何か」を判断するテストオラクル（期待結果の源泉）として、テスト担当者自身の「ドメイン知識（業務知識）」が不可欠になります。
e) 不正解。 電子メールでの記録は、情報の紛失や、プロジェクト全体でのトラッキング（追跡）を困難にする可能性が高いため、推奨される記録方法ではありません。

ポイント

JSTQBにおける「探索的テスト」は、決して「行き当たりばったりのテスト（アドホックテスト）」ではありません。以下のキーワードとプロセスをセットで覚えておきましょう。

テストチャーター（Test Charter）: 「何を、どのような目的でテストするか」を定義したミッションステートメント。詳細なテストケースの代わりになります。
タイムボックス（Timebox）: 探索的テストは通常、中断のない一定の短い時間（例：60分〜120分）を区切って実行されます。この単位を「セッション」と呼びます。
セッションシート（Session Sheet）と記録: テスト実行中に得られた気づき、実行したテスト、見つけた欠陥、発生した問題などをセッションシートに記録します。
デブリーフィング（Debriefing）: セッション終了後、リードやマネージャーと「何を発見したか」「次はどうすべきか」を話し合い、結果を正式に記録します。
ドメイン知識とヒューリスティクス: 仕様書がない（または薄い）状況では、テスターの「業務知識」や「経験則（ヒューリスティクス）」がバグを見つける最大の武器になります。

アドホックテストとの違い 選択肢(c)でアドホックテストへの言及がありますが、JSTQBでは「アドホックテスト（準備や目的がなく、ただ触ってみるテスト）」と「探索的テスト（チャーターに基づき、学習しながら体系的に行うテスト）」を明確に区別しています。