Facebook x

ジャンル

テスト技法・工程
テスト技法・工程 2024.02.07
x hatenabookmark

探索的テストとは|潜在的な不具合を検知する3つ手法とメリット・デメリット

監修: 堀 明広

バルテス・ホールディングス株式会社 R&C部 部長 兼 首席研究員

探索的テストとは|潜在的な不具合を検知する3つ手法とメリット・デメリット

テストを実施する前にはテスト設計とテストケース作成といった準備が必要ですが、開発期間がタイトになると十分な時間を取れないこともあります。

このような場合に有効な方法が「探索的テスト」です。探索的テストは柔軟にテストを進められる、事前にテストケースを作成・実行するスクリプトテストでは検知できないような不具合を発見できる、という強みがあります。

そこで今回は、探索的テストの概要とその実施方法、メリット・デメリットやテストで利用する具体的なツールをご紹介します。

実践!探索的テスト

皆さんは「探索的テスト」というテスト手法をご存知でしょうか? 本資料では、そのような実務上の試行錯誤で培われた探索的テストの知見について、詳しくご紹介したいと思います。

もくじ
  1. 探索的テストとは?基本知識と利用範囲
  2. 探索的テストのメリット・デメリット
  3. 探索的テスト3つの手法
  4. 探索的テストを支えるツール
  5. まとめ

1.探索的テストとは?基本知識と利用範囲

探索的テストとは

探索的テスト.png

探索的テストとは、テスト実行者がテスト内容の作成とテスト実行を同時に並行して行うテスト手法です。形式的テストのように事前にテストケースを作成するのではなく、テスト実行者の知見・経験に基づきながら、潜在的な不具合を検知する可能性の高いテストを集中的に行います。

形式的テストのような網羅的に行うテストでは検知できない不具合を発見できる可能性が高いテストです。

アドホックテストとの違い

探索的テストとアドホックテストの違い.png

探索的テストは、「アドホックテスト」と混同される場合がありますが、テスト目的や内容が定義されているかという点で異なります。

探索的テストにおいては、テストケースを事前に準備しないとはいえ、テストに一定の方向性や目指すところを定めておくことが一般的です。また、テストを実施するにあたって、テストの実行手順やテスト実行者の考えた過程を記録しておくことが推奨されています。

このようにスクリプトテストと同等とは言えないものの、探索的テストはある程度再現性(テストを実行した状況を再現できること)も持っています。

一方のアドホックテストでは、「モンキーテスト」や「ランダムテスト」という言葉と同じ意味、つまり、場当たり的・思いつきで行うテストという意味で用いられることが多く、この場合は探索テストと比べても再現性は低くなります。

したがって、テスト工程でより品質を上げるために正式に導入するテスト手法としては「探索的テスト」を採用すべきだと言えるでしょう。

探索的テストの利用範囲

探索的テストは、テスト工程のどのフェーズでも利用可能ですが、どちらかというとシステムテストやシナリオテストなど、主に広範囲に及ぶテストに用いられる傾向があります。
また、ブラックボックステストでよく実施されますが、ホワイトボックステストや受け入れテストなどでも幅広く活用できます。

2.探索的テストのメリット・デメリット

探索的テストのメリット・デメリットについて解説します。メリットだけでなくデメリットを理解した上で活用していきましょう。

メリット

探索的テストのメリットとしては、以下の点が挙げられます。

  • テスト準備工数が削減できる
  • 仕様書・設計書から想定しにくい不具合の検知が可能

探索的テストは、テストケースの作成、特に詳細な操作方法・期待値の作り込みが不要になるため、開発工数に余裕がない際や開発と並行しながらのテスト実施に適していると言えます。アジャイル開発のような短い開発サイクルを繰り返していく開発プロセスなどにも向いています。

また、テスト実行者は開発・設計時に想定しなかったリスクや不審な動作を検知した場合、臨機応変にテストを進められるため、テストケースには記載されていない項目のテストも実施可能です。これにより、仕様通りの動作やテスト項目の網羅性を確認するテストでは検知し得ない、不具合を発見することにつながる場合もあります。

デメリット

一方で探索的テストのデメリットとしては、以下の点が挙げられます。

  • 属人性が高い
  • 網羅性が保証できない
  • 非機能要求テストには向かない

テスト時の操作や期待値の抽象度が高く、テスト実行者がシステムの操作に不慣れだったり、経験の浅いエンジニアだったりする場合はテスト品質の確保が困難です。

例えば、実行者が特定の分野に偏ってテストをしてしまう、期待値の判断が適切でないという可能性があります。このことは、テスト設計を段階的に行うスクリプトテストと比較して、網羅性が保証できないということにも繋がります。

また、パフォーマンスやセキュリティ、システムの基盤に関わるような非機能要求については、テスト環境の構築に負担がある上、実行者が感覚や経験則で判断できる観点は限られてしまうこともデメリットです。実行者の考えに基づきランダムな動きや結果確認を行う探索的テストは、非機能要件の保証には向きません。

3.探索的テストの3つの手法

探索的テストの手法は、大きく分けて3つあります。それぞれ解説していきます。

① テストチャーターを用いる探索的テスト

テスト前にテストを行う目的と、その目的が達成されたことを判断する指針を設定して行うテスト手法です。このとき、テストの目的を達成するための指針となるものをテストチャーターと呼びます。
例えば、セキュリティバグの確認が目的の場合、典型的なハッキングの手法やセキュリティ事故の事例を参考にテストチャーターを定め、テストチャーターの各項目についてバグがないかを確認していきます。
注意すべきポイントは、テストチャーターの抽象度を程よく保つことです。仕様書通りの挙動をテストチャーターに設定してしまうと、スクリプトテストと変わりません。ある程度テスト実行者の操作や期待値の自由度を持たせておくことで、実行時のシステムの挙動に基づいた動作確認を行うことができるようになります。

② セッションベースドテスト

探索的テストの実施単位(セッション)を一定時間で区切り、それぞれの実施単位ごとにテスト目的(ミッション)とテストチャーターを設けてテスト実行する手法です。各セッションで行うテストはテストチャーターを用いる手法とほぼ同様ですが、時間を区切ることでテスト範囲の網羅性を高める効果があります。

③ フリースタイルの探索的テスト

上記の2つの手法を利用せず、テスト実行者の経験と思考に基づいて実施されるテストです。テスト実行者への依存度は高くなりますが、開発を通じて積み上げてきた傾向や知見を活用することができます。テストを実行しながら、不具合の発生しそうな箇所を感じ取ったり、テストの方向性を修正したりできるなど、柔軟性の高い点が長所です。

4.探索的テストを支えるツール

8607-00027-03

探索的テストは実行者の能力や経験に左右される側面があります。しかし、ツールの活用により、ある程度欠点をカバーすることもできます。例えば、以下のようなツールの活用が有効です。

Capture for Jira

テスト結果や証跡となる画面キャプチャやテスト結果をチームで共有できるツールです。テスト結果のキャプチャに注釈を入れて共有したり、テスト結果についてメンバーで話し合ったりすることができます。テスト実行中に素早くテスト方針を変更したり、有識者の知見をチームにフィードバックしたりするときに役立ちます。

qTest Explorer

テスト実行時のキャプチャ作成・システム操作について、操作が行われた時間やタイミングを記録することができるツールです。操作手順をSeleniumのテストシナリオ(スクリプト)として出力する機能を備えており、テスト自動化にも活用できます。

Rapid Reporter

探索的テストの実行中に、テスト実行者が自身の気付きや行動を記録するためのツールです。セッション中の記録をCSVファイルで出力して、テスト実施後の結果確認や不具合が懸念される箇所の分析に生かせます。

まとめ

探索的テストとは、テスト実行者がテスト内容の作成とテスト実行を同時に並行して行うテスト手法です。本稿で示しているように、探索的テストにはメリットもあればデメリットもあります。テスト実行とテスト内容の作成を同時並行で行う探索的テストは、テスト品質が実行者に依存するものの、うまく活用できればテスト工数削減やシステム品質向上につながる有効な手法です。テストの目的の設定・テスト結果の抽象度を適切に設定すること・有識者の知見を有効活用することが、探索的テストを成功させる鍵となります。

一方で、探索的テストには、「属人性の高さ」「網羅性が保証できない」「非機能要求テストには向かない」というデメリットもあります。探索的テストとスクリプトテストが、互いに補完しあうようにテスト全体をコーディネートするのがポイントです。テストの効率性と品質をワンランク上げるために、探索的テストを活用してみてはいかがでしょうか。

テスト技法・工程
x hatenabookmark

監修: 堀 明広

バルテス・ホールディングス株式会社 R&C部 部長 兼 首席研究員

組込み系プログラマー、ソフトウェア品質管理を経て、現職はバルテス株式会社 R&C部 部長 兼 上席研究員。担当業務は社内人材育成、検証・分析の技術開発、標準化、セミナー講師。訳書は『ソフトウェアテスト293の鉄則』(日経BP、共訳)、『ISO/IEC/IEEE 29119 ソフトウェアテスト規格の教科書』(バルテス、監訳)。著書は『ソフトウェア見積りガイドブック』(オーム社、共著)、『続・定量的品質予測のススメ』(佐伯印刷、共著)、『IT業界の病理学』(技術評論社、共著)。得意分野はバグ分析。