Exploratory Testing

探索的テスト

探索的テストとは

探索的テストという言葉は、フロリダ工科大学 ソフトウェア工学の教授 Cem Kaner の1988年の著書 「Testing Computer Software」で造られた造語 exploratory testing(探索的テスト)が一般的に広まったものだと言われています。

Cem Kaner氏 は Tested = Checked + Explored を提唱しており、ここでのCheckedとは事前にテストを作ることができる「形式的テスト」を指しています。一方、Exploredとは「探索的テスト」のことを指しています。
また、ISTQB®でも「探索的テストは他の形式的なテスト技法を補完する場合に効果が大きい」と説明されており、品質を向上するためには「形式的テスト」「探索的テスト」のどちらも実施することが必要です。

探索的テストはテスト設計と実行、システムについての学習を同時に行い、テストベースを自己で常にアップデートを繰り返すことで、「潜んでいるリスクを探索する」テストです。探索的テストは高度なスキルと、豊富な経験を持ったテストエンジニアでなければ満足のいく効果を出すことが難しいテストでもあります。

以降では、探索的テストにおける各作業をご紹介します。

探索的テストの作業

作業 概要
テスト設計 テスト設計の手法(テスト技法)はすべて、探索に利用することがあります。テスト設計の手法に精通していればいるほど、優れた検証をその場で設計することができます
テスト実行 テストを考えたらすぐに実行することが形式的テストと大きく異なります。即時に実行するからこそ、疑問を感じた事柄をすぐに検証し、問題点を調査に導くことができます。
システムについての学習 探索を進める中で、ソフトウェアの癖と特性について学びます。不具合の潜んでいる僅かな手がかりを探しながら、注意深くシステムの振る舞いを観察します。「観察すること」が重要なポイントで、観察力が高いほど、より多くのものを学べます。観察においては常に仮説を立ててシステムの振る舞いを確認します。
テストベース構築 仮説検証を行うたびに、ソフトウェアの振る舞いについて、少しずつ洞察を得ます。得た知識を使用して、テストベースを自己で再構築(アップデート)します。そして次のテスト設計のインプットに利用し最も重要だと考える不具合に焦点を当てて少しずつ進んでいきます。

探索的テストのテクニック

セッションベースドテストマネジメント

セッションベースドテストマネジメント(Session-Based Test Management、SBTM)は、探索的テストの管理手法の1つです。

探索的テストは、明確なテスト計画やテストケースを作成せずに、テスト対象を探索しながらテストを行う手法です。そのため、テストの進捗状況を把握することが困難であり、テスト管理が難しいという課題があります。

SBTMは、探索的テストの進捗状況を把握し、テストの効率化を図ることができます。SBTMでは、テストを一定の時間(セッション)ごとに区切って管理します。セッションの長さは、45分、90分、120分など、プロジェクトの状況に合わせて決めます。

セッション中はテスト作業以外の割り込み作業を行わずテストに集中します。割り込み作業とは、メール、会議、チャット、電話、チームメンバーからの質問や、テスト対象の変更による中断など、テスト作業以外のあらゆる中断を指します。

セッションの開始時に、テストの目的や目標、テスト対象、テスト範囲などをセッションシートに記入します。セッション終了時には、セッションシートに記載した内容に基づいて、セッションの成果をレポートにまとめます。
レポートには、どのようなテストを行い、どのくらいの時間をかけ、どのようなバグを検出したのかなどを記載します。レポートは、セッション終了時の報告会で使用し、各テスト担当者の成果を確認し合うことで次回のセッションに活用します。

セッションベースドテストマネジメントの特徴
  • 探索的テストの進捗状況を把握しやすい
  • テストの効率化を図れる
  • テストの柔軟性を維持できる

テストチャーター

探索的テストのテストチャーターは、探索的テストの目的や方向性を明確化するための文書です。

探索的テストは、事前にテストケースを作成せず、テストを実施しながらテストケースを作成していくテスト手法です。そのため、テストの目的や方向性が明確になっていないと、テストの成果が十分に発揮されない可能性があります。

テストチャーターには、以下の内容を記載します。

  • ・ターゲット(where):機能、要件、モジュールなど
  • ・リソース(what resource):TOOL、データセット、手法、構成、相互依存する機能など
  • ・情報(what kind of infomation):どんな情報(バグ)を見つけたいか。セキュリティ、パフォーマンス、機能など

記載する際には、「このときはどうなるか?」といった視点で記載すると、テストの目的を広げることができます。また、テストチャーターは何を目的にしているのかを思い出させる程度の粒度で記載し、細かく記載しすぎないことが重要です。さらに、要件開発時からチャーター作りを始めることで、机上で探索をすることにもつながり、要件の漏れや矛盾を早期に発見することもできます。

CONTACT

各種検証サービス・ソリューションのご相談はこちら