― ISTQB Agile Tester Extension 3.3.4 解説 ―
アジャイル開発では、ドキュメントよりも動くソフトウェアと迅速なフィードバックが重視されます。
そのため、すべてのテストケースを事前に細かく設計しておく時間がないことも多いでしょう。
そんなアジャイル環境で非常に有効なのが、**エクスプロラトリテスト（Exploratory Testing）**です。
今回は、ISTQB Agile Tester Extension シラバス「3.3.4 Exploratory Testing and Agile Testing」で解説されている内容をもとに、アジャイル開発におけるエクスプロラトリテストの考え方と進め方をわかりやすく整理します。
■ エクスプロラトリテストとは？
エクスプロラトリテストとは、事前に厳密に設計されたテストケースを用いず、
テスター自身の経験・直感・知識を活かして、ソフトウェアを探索的にテストしていく手法です。
たとえば、
-
仕様書がまだ未完成
-
スプリント期間が短く、詳細なテスト設計を行う余裕がない
-
新しい機能の初期リリースで、動作傾向を早く把握したい
といった状況で特に効果を発揮します。
💡つまりアジャイルでは、**「探索的テスト＝日常的なテストスタイル」**と言っても過言ではありません。
■ エクスプロラトリテストの特徴
|
項目 |
内容 |
|---|---|
|
設計 |
即興的、事前の形式的テストケースはなし |
|
実行 |
テスターの判断で自由に操作 |
|
記録 |
観察結果や気づきをその場でメモ（軽量ドキュメント） |
|
目的 |
想定外の不具合・新たなリスクを発見すること |
|
必要スキル |
製品知識・分析力・好奇心・仮説思考 |
アジャイルでは、**「仕様の抜け」や「ユーザー視点での違和感」**をいち早く発見することが重要です。
そのため、エクスプロラトリテストでは、スクリプトに縛られず、発見力と観察力が問われます。
■ テストチャーター（Test Charter）の活用
完全な自由ではなく、一定の指針を持つことも大切です。
そこで使用されるのが テストチャーター（Test Charter） です。
テストチャーターとは、エクスプロラトリテストを実施するための簡単な「行動計画書」です。
主に以下の情報を記載します。
|
フィールド |
内容 |
|---|---|
|
Tester（実施者） |
誰がテストするか |
|
Purpose（目的） |
何を達成したいのか（例：新UIの操作性確認） |
|
Setup（環境） |
必要な環境やデータ |
|
Priority（優先度） |
他のチャーターとの優先関係 |
|
Reference（参照情報） |
関連するユーザーストーリーやリスク情報 |
|
Activities（テストの流れ） |
どんな操作・観察を行うか |
|
Oracle / Notes（観察結果） |
実際に気づいた点、異常、印象など |
|
Variations（派生操作） |
代替シナリオや別の操作方法など |
テストチャーターは「何を探索するか」を明確にしつつ、柔軟に進めるための“コンパス”のような役割を果たします。
■ セッションベーステストマネジメント（Session-Based Test Management）
エクスプロラトリテストを体系的に進めるために使われる管理手法が、
**セッションベーステストマネジメント（SBTM）**です。
🔸 テストセッションとは？
テストセッションとは、1回あたりの探索的テストの実行単位のこと。
通常は 60〜120分（1〜2時間） の集中した時間枠で行われます。
各セッションの中で1つのチャーターを実施し、結果をまとめます。
🔸 セッションの種類（例）
|
セッションタイプ |
内容 |
|---|---|
|
サーベイセッション（Survey） |
製品全体の挙動をざっくり把握 |
|
分析セッション（Analysis） |
特定機能の機能性・パフォーマンスを重点的に確認 |
|
ディープカバレッジセッション（Deep Coverage） |
境界値や特定条件での深堀テスト |
テスターの経験や観察力が高いほど、セッションの質と発見率も向上します。
■ 探索的テスト中の思考例・質問例
エクスプロラトリテストでは、テスターが常に自問しながら進めます。
代表的な質問例を挙げます。
-
どの部分が最もリスクが高いか？
-
この操作を逆の順序で行ったらどうなる？
-
無効なデータを入力したら？（ネガティブテスト）
-
ユーザーの期待通りの挙動になっているか？
-
異なる環境やブラウザでも動作するか？
このように、「もし〜したらどうなるか？」という思考を繰り返すことで、
スクリプトでは見つけにくい未知の欠陥や潜在的リスクを発見できます。
■ ドキュメントとして残すべき情報
探索的テストは「柔軟」ですが、記録をまったく残さないのはNGです。
後で再現性を確保するために、最低限以下の情報を残しましょう。
|
記録内容 |
具体例 |
|---|---|
|
テストカバレッジ |
どの機能をどこまで探索したか |
|
評価ノート |
観察した問題や気づき |
|
リスクと戦略リスト |
今回のテストでカバーできたリスク、残リスク |
|
問題点・疑問点 |
仕様の不明点、再現しない挙動など |
|
実際の結果 |
スクリーンショット、ログ、操作動画など |
このような記録は、**チーム共有やレトロスペクティブ（振り返り）**でも大いに役立ちます。
■ エクスプロラトリテストのメリットまとめ
|
メリット |
説明 |
|---|---|
|
短期間で効果的な探索が可能 |
詳細設計なしでテスト可能 |
|
経験豊富なテスターの知見を最大化 |
感覚的な異常検知に強い |
|
ドキュメントが少なくても実施可能 |
アジャイル文化と親和性が高い |
|
創造的な欠陥発見 |
定型テストでは見逃す問題を見つけやすい |
■ まとめ
エクスプロラトリテストは、「アジャイル開発における柔軟な品質保証」の中心的な考え方です。
形式的なテスト手法と組み合わせることで、リスクの高い部分を迅速に検証し、
短期間でも高品質な成果を実現できます。
アジャイルテスターとして成功するためには、
単にスクリプトを実行するのではなく、**“探索する姿勢”**が何より重要です。
🧩 この記事のまとめ
-
アジャイルではエクスプロラトリテストが自然に行われる
-
テストチャーターで目的と範囲を明確に
-
セッションベースで短時間集中実施（1〜2時間）
-
観察結果を簡潔に記録して再現性を確保
-
経験と好奇心が品質向上のカギ
コメント