探索的テストとは？

昨今、ソフトウェア開発のスピードはとても速くなってきています。

それは競合他社より先に市場を押さえるためだったり、お客様のニーズが高まった時期にそのチャンスを逃さないためだったり色々な要因があると思います。

開発期間はどんどん短くなり、それに伴って検証時間も短くなる傾向にあります。

それでもテストエンジニアは品質を担保するために、日々頭を悩ませながら試行錯誤を繰り返していることと思います。（私もその1人です。）

皆さんはテスト業務の中で時間が一番かかる部分はどこだと感じますか？

私は、テスト設計・テスト実装の部分が特に時間がかかるなと感じています。場合によっては、テスト実施より時間がかかる事も。

テスト設計やテスト実装で重要なことは、抜け漏れを無くし、誰がそのテストケースを実施しても同じ検証結果になることだと考えます。（個人的な見解です）

「抜け漏れを無くすためにはこのテスト技法を用いて・・・」

「このテストケースってチョット曖昧だから、しっかり最初の操作手順から記載して・・・」

などなど、色々な事を考えて準備をしなければならないので時間がかかります・・・

確かに大規模開発で大勢のテスター（スキルレベルも様々）と一緒に検証を実施していく場合は、管理をするためや、検証品質の均一化、エビデンスを残すためにも重要な事だと考えます。

しかし、小規模開発であったり、とにかく早くリリースしたいなどのオーダーがあった場合などはどうでしょう？これまで通りのプロセスを踏むのが正解なのでしょうか？

現場毎の考え方や状況がありますので、これには正解は無いと思っていますが、一つの回答として、「探索的テストを取り入れる」があると考えます。

▼テストの種類について詳しい内容はこちら▼

探索的テストとは？

では、その探索的テストとはどんなものでしょうか。端的に言うと

「テスト設計・テスト実行・学習を並行して実施していく、経験ベースのテストである」

となります。具体的には、探索的テストではテスト設計書やテスト項目書などを作成せず、エンジニアが頭の中でテスト設計をしながらテストを実行し、その結果から製品の学習をして、さらにテスト設計をする。その一連のプロセスを繰り返すテスト手法になります。

探索的テストでの目的はバグを発見することであり、ドキュメントを作成しないことでテスト工数の大幅な削減を見込めるので、アジャイル開発とも親和性が高いテスト手法です。

また、経験ベースのテストとなっている通り、テストエンジニアのスキルに大きく依存するものとなります。

探索的テストをアドホックテストやモンキーテストと同じに考える方々がいらっしゃいますが、両者は明確に違いがあります。決定的な違いはテスト設計をするか、しないかの違いです。

アドホックテストやモンキーテストでは、何も考えず気の向くままに操作するだけですが、探索的テストでは、前述の通りバグを発見することを目的として頭の中でテスト設計をしながら操作をしていきます。

アドホックテストやモンキーテストとの違い

アドホックテスト/モンキーテストとは

探索的テストとよく似たものとして、アドホックテストやモンキーテストがあります。これらも、ソフトウェアテストの一種であり、対象となるシステムに詳しくないテスト実行者があえてランダムにシステムを操作することで、通常のテスト方法では発見しにくいエラーやバグを見つける手法です。

アドホックテスト/モンキーテストも探索的テストと同様にテストケースを事前に作成せず、その場の直感や思いつきで実施されます。そのため、予期せぬユーザー行動によって発生する問題を特定することが可能です。

ただし、ランダムな操作のため、発見されたエラーやバグの再現性が低い場合があります。

アドホックテストとモンキーテストの違いについては会社や団体によって見解はさまざまで、確立された定義はありません。テストを実行する人のシステムに対する知識の深さにあるという考えもありますが、曖昧な点が多いです。

探索的テストとアドホックテスト/モンキーテストとの違い

探索的テストとアドホックテスト/モンキーテストの違いは、テスト設計の有無にあります。

両者とも事前にテスト設計を行わずに実施する点では共通していますが、探索的テストはテストの目的や手順、観点を明確に定義し、テストチャーターを用意してから実行します。
一方、アドホックテスト/モンキーテストは目的や手順を定義せず、ランダムにシステムを操作します。そのため探索的テストの方が再現性と精度が高く、アドホックテスト/モンキーテストは予測不能なバグを発見するのに適しています。

探索的テストのメリット

探索的テストのメリットをまとめると

• 工数を大きく削減できる

　⇒テスト設計書、テスト項目書を作成しないため

• 不具合を効率よく発見できる

　⇒不具合が潜んでいそうな部分だけをピンポイントでテストできるため

• 仕様漏れ、仕様の誤りを検出できる

　⇒仕様書を元にテストケースを作成するわけでは無いので、仕様書に出てこない部分や整合性が取れていない部分をテストしやすいため

• ユーザビリティ観点でのテストがしやすい

　⇒テスト項目を作るのが難しい（文章化が難しい）、ユーザー目線での使用性の確認がしやすいため

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

探索的テストにはもちろんデメリットもあります。

• テストエンジニアのスキルに大きく依存する
• 進捗の管理が難しい
• 終了規準が明確でない
• 実行エビデンスが残し難い
• 網羅的でない

これらのデメリットの幾つかへは、具体的な対策方法が提唱されているため、それらを利用することで、リスクを軽減することが出来ます。

• テストエンジニアのスキルに大きく依存する

⇒テストチャーターを運用することで、経験やスキルの不足する部分を補い、テストの方向性についても統一させることが出来る。

• 終了基準が明確でない

　⇒探索的テストの実施を短い時間（セッション）で区切ることで、終了基準を明確化し、深追いしすぎるや、確認不足などを防ぐことが出来る。

• 網羅的でない

　⇒スクリプトテストと併用する。例えば基本的な導線や基本機能は、スクリプトテストとして確認の抜け漏れを防ぎ、複雑な観点や組み合わせは、探索的テストで補う様な形を取れば一定の網羅性は担保できる。

テストチャーターとは

ここで、テストチャーターについて概要を説明します。

テストチャーターとは探索的テストの各セッション内での目的を記載した資料になります。

具体的には、テストして欲しい範囲と深さ、条件、観点を記載して、探索的テストの方向性を指示します。

テストチャーターで注意しなくてはならないのは、記載するテスト観点の粒度になります。

探索テストではテストエンジニアのインスピレーションが重要で、それまでの経験や知識によりバグが存在しそうな条件や操作など自由に設計し、テストを実施していきますが、テストチャーターに細かく指示が記載されいるとその内容に捕らわれ、自由な発想を阻害する恐れがあります。

ですからテストチャーターへ記載する観点の粒度は、スキルの低いテストエンジニアには細かく、スキルの高いエンジニアへは粗く、などテストエンジニアのレベルにあわせその都度調整する必要があります。

探索的テストの管理・エビデンスの残し方

探索的テストは、頭の中でテスト設計をしながらリアルタイムでテスト実行をしていくことで、大幅に工数を削減することが出来ますが、その一方でテストがどこまで進んでいるのかや、どんな検証を実施したのかなど、テストの進捗管理や作業エビデンスを残すことが難しいことがデメリットです。

これらについては、進捗やエビデンス残すためのフォーマットを用意して運用するなど、ルールを設定することによりカバーすることが出来ます。

もし、複雑なルールや記入量が多すぎるフォーマットだったりする場合は、エンジニアのインスピレーションを阻害する要因になりますので、注意が必要です。スクリプトテストと探索的テストで集計方法や管理方法が異なるため、テスト管理は煩雑になることが想定されます。

QA業務効率化ならPractiTest

テスト管理の効率化についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで工数を20%削減できる総合テスト管理ツール「PractiTest」がおすすめです！

この記事を書いた人

Dr.T。テストエンジニア。
PractiTestエバンジェリスト。
大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。
2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。