品質をワンランク上げる!テストケースのない「探索的テスト」

最終更新日時:2021.06.01 (公開日:2018.10.19)
品質をワンランク上げる!テストケースのない「探索的テスト」

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

このような場合に有効な方法が「探索的テスト」です。探索的テストは柔軟にテストを進められる、事前にテストケースを作成・実行するスクリプトテストでは検知できないような不具合を発見できる、という強みがあります。
そこで今回は、探索的テストの概要とその実施方法、メリット・デメリットやテストで利用する具体的なツールをご紹介します。

2020/10/9更新 探索的テストの実施方法についてはこちら

探索的テストについて、長年の具体的な経験を記事にしました。ぜひご参照ください!

2021/3/23更新 モンキーテストについてはこちら

モンキーテストに関する記事を公開いたしました。以下の記事もご参照ください。

探索的テストに関する具体的な

テストケースを作成せず行う「探索的テスト」

8607-00027-02

探索的テストとは、テスト実行者がテスト内容の作成とテストの実行を同時に並行して行うテスト手法です。あらかじめテストケースを作成するのではなく、ソフトウェアの振る舞いやテスト結果を見ながらテストを実行します。

探索的テストでは、テスト実行者の知見・経験に基づきながら、潜在的な不具合を検知する可能性の高いテストを集中的に行います。
予めテストケースを用意して実施するスクリプトテストのようなパターン網羅的なテストでは検知できない不具合を発見できる可能性も高いというメリットがあります。

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

探索的テストは、「アドホックテスト」と混同される場合がありますが、似て異なるものです。

「アドホック」とは「ad hoc」というラテン語から派生したもので、「特定の目的のための」「その場限りの」という意味です。
探索的テストとアドホックテストは人によって認識が異なる場合が多く、両者ともに同じような意味で用いられることもありますが、「テスト目的や内容が定義されているかどうか」という点で異なります。

探索的テストにおいては、テストケースを事前に準備しないとはいえ、テストに一定の方向性や目指すところを定めておくことが一般的です。また、テストを実施するにあたって、テストの実行手順やテスト実行者の考えた過程を記録しておくことが推奨されています。
このようにスクリプトテストと同等とは言えないものの、探索的テストはある程度再現性(テストを実行した状況を再現できること)も持っています。
一方のアドホックテストは「モンキーテスト」や「ランダムテスト」という言葉と同じ意味、つまり、場当たり的・思いつきで行うテストという意味で用いられることが多く、この場合は探索テストと比べても再現性は低くなります。

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

探索的テストの利用範囲

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

探索的テストの種類

探索的テストの種類は、大きく分けて3つあります。

【1】テストチャーターを用いる探索的テスト

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

【2】セッションベースドテスト

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

【3】フリースタイルの探索的テスト

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

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

探索的テストのメリットとしては、「テスト準備工数の削減」「仕様書・設計書から想定しにくい不具合の検知が可能」といった点が挙げられます。
探索的テストは、テストケースの作成、特に詳細な操作方法・期待値の作り込みが不要になるため、開発工数に余裕がない際や開発と並行しながらのテスト実施に適していると言えます。アジャイル開発のような短い開発サイクルを繰り返していく開発プロセスなどにも向いています。
また、テスト実行者は開発・設計時に想定しなかったリスクや不審な動作を検知した場合、臨機応変にテストを進められるため、テストケースには記載されていない項目のテストも実施可能です。これにより、仕様通りの動作やテスト項目の網羅性を確認するテストでは検知し得ない、不具合を発見することにつながる場合もあります。

一方で探索的テストのデメリットとしては、「属人性の高さ」「網羅性が保証できない」「非機能要求テストには向かない」という点が挙げられます。
テスト時の操作や期待値の抽象度が高く、テスト実行者がシステムの操作に不慣れだったり、経験の浅いエンジニアだったりする場合はテスト品質の確保が困難です。例えば、実行者が特定の分野に偏ってテストをしてしまう、期待値の判断が適切でないという可能性があります。このことは、テスト設計を段階的に行うスクリプトテストと比較して、網羅性が保証できないということにも繋がります。

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

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

8607-00027-03

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

Capture for Jira

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

qTest Explorer

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

Rapid Reporter

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

まとめ

本稿で示しているように、探索的テストにはメリットもあればデメリットもあります。
テスト実行とテスト内容の作成を同時並行で行う探索的テストは、テスト品質が実行者に依存するものの、うまく活用できればテスト工数削減やシステム品質向上につながる有効な手法です。テストの目的の設定・テスト結果の抽象度を適切に設定すること・有識者の知見を有効活用することが、探索的テストを成功させる鍵となります。
一方で、探索的テストには、「属人性の高さ」「網羅性が保証できない」「非機能要求テストには向かない」というデメリットもあります。
探索的テストとスクリプトテストが、互いに補完しあうようにテスト全体をコーディネートするのがポイントです。
テストの効率性と品質をワンランク上げるために、探索的テストを活用してみてはいかがでしょうか。

執筆者:Qbook編集部

ライター

バルテス株式会社 Qbook編集部。 ソフトウェアテストや品質向上に関する記事を執筆しています。