探索的テスト: アジャイル開発で効果的に実施する方法

Hannah Son著

探索的テストはスクリプトに依存しない動的なソフトウェアテストアプローチであり、テスターは形式化されたスクリプトではなく特定の目標に基づいてアプリケーションを評価します。この手法は、ユーザーの観点から未知のリスクや不備を明らかにするのに特に効果的です。

探索的テストのメリットを最大化するには、以下を重視します。

ドメイン知識を活用する: アプリケーションやユーザーニーズに関する知識をテストの指針として利用します。
創造性と直感を働かせる: 自然な好奇心に従ってソフトウェアを探索します。

最も一般的な探索的テストの実施方法は、セッションベーステスト管理（SBTM サイクル）の5つのステージに従うことです。

テストのミッションまたはゴールを定義する
テストチャーターを作成する
テストをタイムボックス化する
結果をレビューする
デブリーフィングを行う

探索的テストを構造化する方法
探索的テストのサンプル
アジャイルテスト管理ツールを使用した探索的テストの実行
- テスト管理ツールを使用して探索的テストをレポートする方法
探索的テストFAQ
関連する製品
- テスト管理ツール TestRail
  - ■ TestRailの特長 ■

探索的テストを構造化する方法

探索的テストは従来のスクリプト化されたテストよりも自然発生的で順応性が高いものですが、時間ベースのSBTMサイクルアプローチによってステップごとに構造化されます。

1.テストのミッションまたはゴールを設定する

まず、探索的テストセッションのミッションを明確に定義します。すると、重要な領域に作業を集中させ、確実に対処することができます。具体的には以下の手順に従います。

よくあるバグを識別する: 過去のプロジェクトや類似のソフトウェアをレビューし、重要度および優先度ごとにバグを分類します。
以下の質問に答えを出す:
- 問題につながったイベントは何か？
- どのシステムや個人が関連していたか？
根本原因を文書化する: 画面ショット、コメント、固有の問題などを記録して問題を明確化します。
テストシナリオを作成する: わかったことに基づいてリスクを特定し、アプリケーションに合わせてテストシナリオを作成します。

2.テストチャーターを作成する

テストチャーターとは、ミッションステートメントの役割を果たす簡潔な概要レベルの指針であり、探索的テスト作業を集中させ、変化する状態に適応すると同時に、創造性を発揮する余地を残すのに役立ちます。

たとえば、EコマースプラットフォームのWebアプリのログインをテストする場合、テストチャーターは「ホームページのログインメニュー機能を分析し、潜在的リスク領域をレポートする」、「Webアプリケーションのログイン機能を分析する」、あるいは「不正なデータを持つユーザーがWebアプリにログインできるかどうかを確認する」等になるでしょう。

チャーターは、コースを外れないようにし、不注意による特定のリスクを最小限にするためのものです。テストチャーターを作成する際は、以下を含めるべきです。

セッションの主要なミッション
テスト対象領域や機能、およびテストの方法
関係するリスクおよび前提
期待される結果や派生物、およびユーザーのシステム利用方法
セッションで利用する方法またはツール

探索的テストチャーターの例

テストチャーターは、探索的テストセッションの簡潔な概要レベルの指針となります。チャーターは、作業を集中させると同時に、創造性を発揮する余地を残すのに役立ちます。効果的なテストチャーターを作成するには、以下の手順に従います。

ミッションを定義する: テストセッションの主要な目的を明確に記述します。たとえば、「ホームページのログイン機能に潜在的リスクがないか分析する」などです。
対象領域を指定する: テストする予定の機能または領域を指定します。ユーザーログイン、チェックアウトプロセス、特定のアプリケーション機能などの側面を考慮します。
リスクおよび前提の概要を記述する: テストに影響を与える可能性がある既知のリスクまたは前提条件があれば文書化します。これは作業のコンテキスト情報となります。
期待される結果を詳細に記述する: 達成するべきねらいおよびユーザーがシステムとどのようなやり取りを行う可能性があるかを説明します。これによってテストセッションに明確な期待値を設定します。
方法およびツールをリスト化する: セッションで探索の指針として使用する予定の方法(経験則)またはツールがあれば言及します。

例: たとえば、ソーシャルメディアアプリケーションのチャーターであれば、「同一グループ内の複数ユーザーのコメント、パーミッション、競合状態をテストする」といったものが考えられます。明確なテストチャーターを作成することで、漠然としたテストプロセスを構造化されたリスク探索に変えることができます。

3.テストをタイムボックス化する

タイムボックス化とは、テスターがあらかじめ決められたタイムフレーム内に作業を集中させるためのテクニックです。タイムボックス化により、集中力と効率性が増します。探索的テストセッションを効果的にタイムボックス化するには、以下の手順に従います。

時間を設定する: セッションの制限時間を決定します。通常は60分から90分です。これは集中力を維持し、疲労を防ぐのに役立ちます。
ペアで作業する: 理想的には、2人のテスターが協力してセッションを実施します。このような協働的アプローチは、創造性を拡大し、より徹底的な探索を可能にします。
中断を最小限にする: テスターが集中できるよう、タイムボックス中は邪魔が入らないようにします。テスト専用のスペースを使用することを検討します。
必要に応じて調整する: テストの進捗に応じてタイムボックス時間を柔軟に調整します。深刻な問題が見つかった場合は45分までを目途にセッションを延長したり、必要事項をすべてカバーした場合は時間を短縮したりするとよいでしょう。

タイムボックス化を実践すると、構造化され、しかも柔軟な環境を用意することができ、探索的テストの有効性を最大化できます。

4.結果をレビューする

結果をレビューすることは、探索的テストセッションの有効性を評価するうえで重要です。以下の手順に従って徹底的にレビューします。

結果を文書化する: セッション中に遭遇したバグおよび問題をただちに記録します。画面ショット、詳細な説明、その他の関連情報を使用してコンテキストを提供します。
バグを評価する: バグを解析し、重要度およびさらに調査が必要かどうかを決定します。以下を検討します。
- この課題をレポートするのに十分なエビデンスがあるか？
- このバグはユーザーエクスペリエンスにどのような影響を与えるか？
カバレッジを評価する: テストした領域を振り返ります。その後のセッションで対処するべきカバーされていない領域があるかどうか検討します。
結果を整理する: 結果を明確で構造化されたフォーマットにまとめます。これはデブリーフィングセッションでの議論を容易にします。

結果を徹底的にレビューすると、探索的テスト作業が十分に文書化され、開発チームによる対処が可能であることを保証できます。

5.デブリーフィングを行う

デブリーフィングは、セッションベーステスト管理プロセスに欠かせません。デブリーフィングによって、テストを振り返ってその後のセッションを改善することが可能になります。効果的なデブリーフィングを行うには、以下の手順に従います。

チームを招集する: セッションに関わったテスターならびに適切なステークホルダーを集めます。すると、コラボレーションが促進され、すべての側面を確実に検討できます。
結果をまとめる: 探索的テストセッションの知見を提示し、テストチャーターに記載された期待される結果と実際の結果を比較します。
問題およびリスクを特定する: テスト時に発見された重大な欠陥またはリスクがあれば議論します。さらに注意やテストが必要な領域を明らかにします。
改善策を議論する: うまくいったこと、今後のテストセッションで改善可能なことを振り返ります。以下を検討します。
- 予期しない課題があった場所はどこか？
- 前進するためにどのようなテストアプローチの拡張が可能か？
結果を文書化する: デブリーフィング中に得られた洞察を明確に記録します。この文書は、その後のセッションでの参考資料となり、長期にわたる進捗を追跡するのに役立ちます。

徹底的なデブリーフィングを行うことで、継続的な改善につながるため、常に探索的テストの有効性が保たれ、変化するニーズに適応することができます。

**画像:** TestRailはリアルタイムのレポートを実現し、報告されたすべてのメモ、スクリーンショット、および欠陥を時系列で一覧できる履歴を保持しているため、簡単にすべてのテストセッションを一元的にレビューできます。

デブリーフィングは軽視されがちですが、重要な情報支援であり、テストマネージャーがアプリケーション品質を感覚として掴み、カバレッジの全体的な視野を得るのに役立ちます。デブリーフィングでのフィードバックには、テスト目標に対する進捗の評価や、検出された最も重要な欠陥のサマリーを含めることができます。

探索的テストのサンプル

以下は、探索的テストがどのように行われるかを示すサンプルです。

シナリオ: あなたはWebベースのE-コマースアプリケーションのテスターです。

テストチャーター: あなたのゴールは、チェックアウトプロセスのユーザビリティおよび機能をテストすることです。
探索: まず、商品のブラウズ、カート管理、支払いプロセスなどのアプリケーションの主要な機能に慣れることから始めます。

実施:

ショッピングカートにアイテムを追加し、チェックアウトに進みます。アイテムを追加または削除したときにカートが正しく更新されないなどの問題がないか注意します。
バグに遭遇したら、以下のような情報を含めて文書化します。
- 問題の画面ショット
- 予期しない動作の説明
発見に基づいてテストを調整します。たとえば、カート内でのアイテムの管理方法に矛盾があるのに気づいた場合、該当機能をさらに探索し、別の組み合わせでアイテムの追加や削除を試します。

継続的フィードバック:

バグが見つかったらすぐに開発チームにレポートし、すばやいフィードバックループによってソフトウェア全体の品質に貢献できるよう努めます。

この探索的テストによって、スクリプト化されたテストでは見逃しのおそれがある問題を発見すると同時に、開発チームとのすばやいコミュニケーションによってアプリケーションの品質向上を図ることができます。

アジャイルテスト管理ツールを使用した探索的テストの実行

チャーターを使用した探索的テストは、デリバリーにかかる時間が比較的短いため、アジャイル環境で有効です。しかし、探索的テストの結果を共有スプレッドシートで追跡するのは大変な作業であり、詳細が失われる可能性があります。結果をネットワークドライブ上の個別のドキュメントで管理する場合はさらに大変かもしれません。

TestRailでは、チャーターをテストケースとして保存できます。その後、特定のリリースで実施すると決めたさまざまなタイプの探索的テストで構成されるテストランを作成できます。

***画像:*** *TestRailでは、テストケースを追加し、*「*exploratory session*」*テンプレートを選択して推定時間、ミッション (探索的テストの目的)、ゴール (検証する特定の領域)を追加できます。*

テスターはセッションと同様にテストケースにコメントを残すことができます。すると、テスト管理システムがデータを収集してサマリーレポートを作成します。

スクリプト化されたテストと探索的テストを組み合わせた比較的シンプルなアプリケーションの例では、テストランは20個のスクリプト化されたテストケースと特定のリスクを探索するための4つのチャーターで構成されるといったケースが考えられます。次のサンプルでは、セッションをテストケースとして記録しています。

***画像:*** *セッションをテストケースとして記録することで、TestRailで探索的テストを実行する*

テスト管理ツールを使用して探索的テストをレポートする方法

効果的なレポートは、ステークホルダーが探索的テストの結果を確実に理解できるようにするうえで重要です。以下の手順に従って、明確でアクションを起こすのが容易なレポートを作成します。

キーとなる結果を強調する: レポートの先頭に探索的テストセッションで見つかった最重要問題および結果のサマリーを記述します。
対処可能な洞察を提供する: 結果に基づいた具体的な推奨事項を記述します。たとえば、今後テストするべき領域やアプリケーションの改善策を提案します。
カバレッジおよび品質レベルをわかりやすく示す: メトリクスやビジュアル表現を使用して、テスト時にカバーされたアプリケーションの側面や、ソフトウェアの全体的な品質および信頼性レベルをわかりやすく示します。
構造化されたレポートツールを使用する: TestRailなどのテスト管理ツールを使用して結果を整理します。結果をテストケースとして構造化すると、何がテストされ、何が残っているのかをステークホルダーが容易に理解できます。
明確にコミュニケーションする: レポートを容易に理解できるようにします。明確な言葉遣い、簡潔なサマリー、主張を裏付ける適切な例を使用します。すると、ステークホルダーが結果の意味をすばやく理解できるようになります。

***画像:*** *TestRailなどの専用のテストケース管理プラットフォームを探索的テストツールとして使用して、探索的テストケースのレポート生成プロセスを管理、整理、追跡、合理化します。*

探索的テストFAQ

スクリプトテストと探索的テストの違い

スクリプトテストは具体的な手順が事前に定義されたテストケースに従ういっぽう、探索的テストでは、テスターが直感に従ってソフトウェアを探索し、問題を発見して動作を評価するという、スクリプトに頼らないアドホックテストが行われます。

次の表は、スクリプトテストと探索的テストの主な違いを分類したものです。

側面	スクリプトテスト	探索的テスト
テストケースの作成	事前に定義されたテストケース	事前に定義されたテストケースなし
テスト実行	スクリプトに記述された手順に従う	アドホック、スクリプトなし
テスト計画	詳細なテスト計画が必要	それほど形式的ではないテスト計画
柔軟性	柔軟性が低い	柔軟性が高い
テストの文書化	広汎な文書化	最小限の文書化
テストカバレッジ	具体的で限定的	広いテストカバレッジ
自動テスト	自動テストに非常に適している	自動化に適していない（人間の直感と好奇心が必要）
バグ検出	新しい問題の発見にはそれほど有効ではない	隠れた問題の発見に有効
ユースケース	反復的タスクに適している	新機能のテストに適している

探索的テストのタイプ

フリースタイル探索的テスト: テスターは特定のガイドラインなしでソフトウェアを探索するため、有機的な欠陥検出が可能です。
シナリオベースの探索的テスト: 特定のユーザーシナリオにフォーカスし、実際の使われ方をシミュレートして動作を評価します。
セッションベースの探索的テスト: タイムボックス化されたセッションで構成されます。各セッションはソフトウェアの個別の側面をターゲットとします。
ペア探索的テスト: 2人のテスターが協力し、それぞれの洞察を総合することで、より効果的に欠陥を発見します。
アドホック探索的テスト: 最も形式的ではないタイプの探索的テストであり、系統的なアプローチなしにテスターの直感と経験だけに頼ってテストを行います。

どのタイプの探索的テストを選択するかは、テストの目的、ソフトウェアの性質、テストチームの持つ知見によります。多くの場合、カバレッジと欠陥の発見を徹底するため、複数のテストが組み合わせられます。

探索的テストを採用するべきケース

早期テスト: 詳細なテストケースがまだ利用できないときに問題を発見します。
ユーザビリティテスト: ユーザーフレンドリーかどうかを評価し、現実的なユーザーの問題を検出します。
複雑なシステム: 複雑なアプリケーションに対応し、問題を発見します。
迅速なフィードバック: アジャイル環境ですばやく洞察を提供します。
適応的テスト: 要件の発展に効果的に対応します。
非機能テスト: パフォーマンス、セキュリティ、信頼性の脆弱性を検出します。
新機能のテスト: 新規実装に伴う統合の問題を発見します。

探索的テストは、適切にテストを行うために柔軟性、適応性、予期しない問題を発見する能力が重要な場合に有効です。探索的テストはソフトウェア品質に関するより全体的なビューを提供することでスクリプトテストを補います。

アジャイルでの探索的テストの利点

探索的テストには、アジャイル開発環境においていくつかの重要な利点があります。

柔軟性と適応性: アジャイル開発の特徴は、変化する要件と頻繁な繰り返しです。探索的テストはスクリプト化されていないため、変化にすばやく適応し、テストを常に最新の有効な状態に保つことができます。
迅速で継続的なフィードバック: 探索的テストはアジャイルチームに即座にフィードバックを返すため、開発サイクルの早期に問題を発見できます。これによって、すばやくバグを解決し、継続的に改善を行うことができます。
ユーザーニーズに対応する: アジャイルは現実のユーザーニーズに応えるソフトウェアをリリースすることをねらいとします。探索的テストはテスターが実際の利用シナリオをシミュレートし、スクリプトテストでは見逃される可能性があるユーザビリティや機能上の問題を発見することを可能にします。
創造性の向上: テスターは自身の創造性と直感を働かせ、スクリプトテストでは発見できない可能性があるエッジケースでの欠陥を発見できます。探索的テストアプローチはエンドユーザーの立場になって考えることを促し、潜在的なペインポイントやユーザビリティの懸念を識別するのに役立ちます。
テストカバレッジ増加の可能性: 探索的テストは事前に定義されたスクリプトに縛られないため、広範囲をカバーできます。テスターはさまざまなパスやインタラクションを探索し、より広いテストシナリオが検証されるよう保証できます。
早期検証: アジャイルチームは探索的テストによって、ユーザーストーリーや機能が実装されたらすぐに検証できます。これは、イテレーションを重ねるうちに欠陥が累積するリスクを低減するのに役立ちます。
リスク軽減: スケジュールがタイトなアジャイルプロジェクトでは、リスクの高い領域を早期に識別するのに探索的テストが役に立ちます。これによって、有効にリソースを配分し、重大な問題にすばやく対応できるようになります。