探索的テストはテストケースを書かないって本当？ 探索的テストのメリット・デメリットをわかりやすく解説

「探索的テスト（Exploratory Testing）」とはJSTQB用語集（※1）では「テスト担当者がテストアイテム（※2）や以前のテストの結果の知識や調査情報を使用して、テストを動的に設計、および実行するテストアプローチ。」と定義されています。つまり、テストをした結果をもとにテスト対象のプロダクトのシステムを学習し、どのようなテストを行えば欠陥が見つかりそうかを考えながらテスト設計を行っていきます。また、事前にテスト設計を行う必要がないことから、 同様の理由から事前に準備がかからずスピーディーに実施できることから、特にアジャイル開発と相性がよいとされています。 近年では開発手法としてアジャイル開発が取り入れられるケースも増えており、探索的テストに対する注目度がより高まっています。

また探索的テストは、仕様書に記載されていない検討が不足している機能や、仕様上で論理が矛盾している機能に対してもテストを行うことができるため、従来の「記述式テスト（スクリプトテスト）(※3)」を補完する役割も併せ持っています。

注目度が高まっている探索的テストにもメリットだけでなくデメリットも存在します。
メリット・デメリットを把握したうえで、探索的テストの手法を取り入れる必要があることから、ここでは主なメリット・デメリットを紹介します。

探索的テストは事前にテストケースを用意する必要がないので、テスト設計の修正・レビューにかかるコストを削減できます。
また事前に準備がかからずスピーディーにテストを開始できるため、不具合の検出のタイミングも早くなり、テスト対象の品質を素早く向上、またリリースタイミングを早めることにもつながります。

一般的にソフトウェアテストでは仕様を固め、それを設計書におこしていく作業が必要なため、仕様が固まっていない場合は仕様の検討に時間を要し、その分テストのスケジュールが後ろ倒しになってしまう、なんてことも起こりえます。

その点探索的テストは、テストを行いながらそのテスト対象のプロダクトのシステムを学習し、またテストの結果に応じて、新たに欠陥が見つかりそうなテストケースを設計していくため、仕様が未確定であったり、ドキュメントとして記されていない場合にも有効な技法といえます。

テストの7原則の1つである「殺虫剤のパラドックスにご用心」とは、JSTQBシラバス（※4）では「同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなる」ということを表しています。

各テストケースによって発見された欠陥は、その都度修正されるので、再度同じテストを繰り返しても欠陥が見つかりにくくなる、つまり異なる観点のテストで検出される欠陥は残りつづけます。ですが、探索的テストはソフトウェアの実際の動作から欠陥の存在が疑われる箇所を見当してテストを実施するため、固定化されたテスト観点にとらわれることがありません。

よって、テストケースベースドテストで欠陥があまり検出されなくなった場合でも、探索的テストは新しい欠陥を検出することができます。

メリットの2でお伝えしたように、探索的テストは仕様書がない場合にも有効な技法ですが、仕様が不十分である場合にはある程度仕様を予想しながらテストを行う必要があります。

また、どのようなところにバグが潜んでいるかも見当をつけながらテストを進める必要もあり、一定のスキルや経験が求められるため属人性が極めて高くなります。

何度もお伝えしている通り、探索的テストは初めにテストケースを用意しないため、実施されるテストの全量が把握できないというデメリットがあります。

すなわち、いま行っているテストが全量分のどの程度なのかの計算ができないため、進捗管理も難しくなります。

一般的にソフトウェアテストでは、テスト実施前に仕様をもとにテストケースを作成するため、テスト設計の段階で仕様の不備などに気づくことができます。これはつまり、欠陥のつくり込みを防ぐことにつながります。しかし探索的テストでは、テストを実施しながらテスト設計を行うため、テスト開始前に欠陥の発生を予防することはできません。

探索的テストと同じようにテストケースを作成せずに実施するテスト技法で、「アドホックテスト」「モンキーテスト」があります。それぞれの特徴と、探索的テストとの違いについても解説していきます。

JSTQBの用語集では、「公式なテストの準備をせず、仕様やコードのような公式な情報をもとにしたテスト設計を行わず、テスト結果も予測せずに実施する」と定義されています。

「アドホックテスト」の「アドホック」には、「その場限りの」「場当たり」という意味があり、場当たり的に思いつくまま行うソフトウェアテストの手法です。

ただ場当たり的に行うといっても何の脈絡もなく行っていいということではありません。アドホックテストの精度を高めるためには、システムのどんなところにバグが潜んでいそうか、ある程度の予測が必要となります。

そのため、ソフトウェアの仕様を理解した一定以上の知識やスキルを持った技術者による実施が必要となります。

JSTQBの用語集では、「製品の使用方法を全く考慮せずに広範囲の選択肢から『ランダムに選択』して、ボタンを『ランダムに押す』ことでテストを行なう方法」と定義されています。

モンキーテストでは文字通り、猿（モンキー）に操作させるように、開発者が想定していない操作やイレギュラーな値の入力の値などをランダムに行うことにより、テストケースを作成して実施するテストでは見つけにくい不具合を見つけることができます。また、必要なのはランダムな操作となるため、アドホックテストとは異なりソフトウェアテストの仕様に関する知識、またスキルがない担当者でも実施することができます。

テストケースを用意せず、手探りで行うソフトウェアテストの手法として、探索的テストとアドホックテスト・モンキーテストはよく混同されます。
大きな違いは3つ。

1つ目は事前準備があるということ。探索的テストはテストケースこそ作成しないものの、テスト計画時に探索的テストの目的を定め、またテストチャーター（※5）を用意してから実行します。

2つ目は実行手順・結果の記録。アドホックテスト・モンキーテストは実行手順・結果を記録せずテストを進めるのでコストもあまりかからず実施できるメリットがあります。一方探索的テストは記録することが推奨されています。しかしその分アドホックテスト・モンキーテストと比べて精度が高く、高い効果を出しやすくなります。

3つ目は、アドホックテスト・モンキーテストはあくまで仕様をもとにして場当たり的に、ランダムにテストを行いますが、探索的テストは仕様書に記載されていない検討が不足している機能や、仕様上で論理が矛盾している機能に対してもテストを行います。そのため仕様をもとに設計される「記述式テスト（スクリプトテスト）」を補完する役割も担っています。

探索的テストはなぜ効果が高いといわれているのか？
数あるテスト技法のなかで、なぜ探索的テストは効果が高いといわれているのでしょうか。

テスト対象となるシステムは非常に複雑です。テストを実施するプロダクトは、そのプロジェクトのなかで開発したソースコードだけで完結しているわけではありません。よって開発時に使用するフレームワークの想定外の仕様が予期せぬ挙動を引き起こすこともあれば、ハードウェア、ミドルウェア、外部システムとの連携部分に意外な落とし穴があることも・・・。

いまやプロダクト単一で見ても非同期処理は当たり前の時代ですので、設計時には想定していなかったタイミングでのイベントの発火や処理の出力で予期せぬ結果がアウトプットされることは容易に想像できるかもしれません。

ですが、それらの相互作用をテスト実行前に完全に書き出して設計することは非現実的となります。

例えば、店舗ごとに社員情報を一覧で表示するシステムがあります。このシステムはデータベースからデータを引っ張って情報を表示しています。ところがA店では社員が存在しているのにもかかわらず、A店の社員一覧を表示させようとするとエラーが表示されてしまうことがわかりました。

このエラーはなぜ起きたのか・・・。結論として、A店の社員データの1つに未入力で登録されていた項目があり、その未入力項目をシステム上でどのように表示させるかを決められていなかった。

結果としてそれが欠陥となり、A店の一覧が表示されないという故障につながってしまった、という事例。

この不具合をユースケーステストで検出しようとするとどのような準備が必要になるでしょう。ユースケースとしては「A店の社員がA店の社員一覧を参照できること」という観点で、「社員データは事前に用意しておくこと」が前提条件となります。

この不具合を検知するには、前提条件として未入力項目をもったレコードを用意する必要がありますが、テストの前提条件にあらゆる例外を考慮しようと思うと、運用上発生し得ないパターンも加味しなければならず、設計的にもデータ準備的にも労力が大きすぎることが想像できるかと思います。

多くの場合、前提となるテーブルレコードは正常な状態のパターンのみを想定しテスト設計を行うのではないでしょうか。一方で、探索的テストの場合、アプリケーションを操作するなかで、その画面で使用される要素、状態、データから、実行者は想定される不具合を予測して、その場でテストを設計します。

今回であれば、入力系の機能ではNull値や未入力はバグリスクが高いという経験則に基づいて、社員データの一部を未入力で登録をかけてみます。そして、登録が運用上可能であることを確認した時点ではじめて、社員データの一部に欠損がある状態での社員データの参照系の操作は問題ないか確認を行います。こうすることでテストケースを大幅に削減しつつも、欠陥をきちんと検知することができます。

効果が高いといわれている探索的テストですが、便利であるが故に間違った認識や使われ方が見受けられるケースも。
以下で代表的な探索的テストのアンチパターンを見ていきましょう。

そもそも探索的テストはテストの目的や終了の目安だけを決め、細かいテストケースを事前に作成せずに行うテストとされています。しかし、「テストケースに漏れがないか不安だから」「テスト期間が少し余っているから」といった理由で、特定の目的をもたずに探索的テストを実施しているケースが見受けられます。

目的をもたずに探索的テストを行った場合、どのような影響があるでしょうか。

まず、テスターが何のために何を行っているのかが可視化されないため、品質が担保されているかがわからずリリース判断ができません。テスター自身も目的をもたずに探索的テストを行った場合、的外れなテストを行ってしまうことや、テスターの技量によって見るべき観点がぶれてしまうことも十分に考えられます。そうなると、余計に時間がかかってしまう可能性もあり、効率的であるという探索的テストのよさを活かしきれません。

また、目的をもって探索的テストを計画していたとしても、それを周知しないとただのテスターの自己満足になってしまいます。

例えば、探索的テストの立ち位置を機能テスト・シナリオテストで事前に計画した不具合検出率を下回った場合に行うもの、と決めたとします。実際に機能テスト・シナリオテストを実施したところ、不具合検出率も計画通りの数値となり、十分な品質が保証されていると判断し、テスターは探索的テストを行わない判断をしました。

しかし、探索的テストの目的・立ち位置を周知していない場合、まわりは「計画時よりもテストケースを減らしているけど本当に大丈夫なの？」と捉えかねません。

何度もいうようではありますが、探索的テストは事前にテストケースを作成せず、テスターが実際に操作したりプログラムの挙動を見ながら、気になる箇所を次々にテストしていき、結果を記録してフィードバックするものです。

なぜ、実行手順・実行結果を残す必要があるのか。

例えば、何か不具合があった際に実行手順を残しておかないと不具合の再現方法がわからなくなってしまう可能性もあり、欠陥がどこにあるのか見つけるのに時間がかかってしまう場合もあります。また、実行結果を残していないとテストをやっていないも同然となり、品質が担保できているかがわからずリリース判断ができません。

そういった場合、リリース判断がくだせるよう再テストを行うことになりますが無駄な時間がかかってしまいます。

上記のようなアンチパターンが散在するなかで、どのようなことに気をつけて探索的テストを行えばよいのでしょう。
押さえておかなければいけないことは3つあります。

①テスト戦略で探索的テストの目的を定める

②探索的テストをドキュメント化する

③探索的テストの目的・ドキュメントをチーム内に共有する

では一つずつ見ていきましょう。

そもそも目的をもたずに「テストケースに漏れがないか不安だから」「テスト期間が少し余っているから」といった理由で探索的テストを行おうとしてしまうのは、テスト戦略時に探索的テストを行うことを考えられていないからです。

テスト戦略では、テスト対象の把握→テストリスクの把握→テストアプローチの検討の順で進めます。そのなかで、テストアプローチでは、テスト対象の概要、リスクを洗い出したうえで、具体的にどのようにテストを実施していくのかを決定していきます。ここで探索的テストの特性を考慮し、探索的テストの実施を決定することができれば、自ずと目的は定まるのではないでしょうか。

これは探索的テストに限った話ではありません。品質保証のためのテストでは、手順通りにテストを実施したこと、その結果品質がリリースの判断基準に沿っていること（沿っていないこと）を表すために「エビデンス」を残す必要があります。

探索的テストも同様に、どのような手順でテストを実施し、どのような結果になったのかをドキュメント化する必要があります。またテスト手順・結果を記録することで、ただ「エビデンス」を残すだけでなく、検討できていなかった仕様にも気づくきっかけにもなり、さらなる品質の向上が見込める場合もあります。

ただドキュメント化するのは非常に労力がかかる作業でもあります。

そういった場合は、ドキュメント化＝テキストと考えるのではなく、ドキュメント化の目的、「手順通りにテストを実施したこと、その結果品質がリリースの判断基準に沿っていること（沿っていないこと）を表すために『エビデンス」』を残す」に立ち返りましょう。

何も時間をかけてテキストで残さずとも、手順から結果までを動画で撮るのも大いに有効だと思いますし、画面のキャプチャをとって、PPTスライドに手順から結果までを簡単にまとめておくだけでも目的はクリアされるかと思います。

どのように工夫してドキュメント化すれば、探索的テストの効率のよさを活かしたまま進めることができるか、を考えてテストを実施していくことが大切ですね。

テスト戦略で決めた探索的テストの目的やテスト実施時のドキュメントはチーム内で共有することが必要です。テスターの独りよがりなテストとせず、チーム全体で品質が担保できているかを認識でき、リリース判断がもてるようチーム内への共有を忘れず行いましょう。

本コラムでは、探索的テストは何か、どのように行っていくべきか、をアンチパターンを元に解説しました。

便利がゆえに、間違った認識や使い方がされてしまう探索的テスト。本コラムを機に再度探索的テストの特性を確認し、その特性を存分に活かせる手法で実践することで、品質保証に貢献していってもらえたらうれしいです。

備考
（※1）JSTQB用語集：ソフトウェアテスト標準用語集Version3.2.J01
（※2）テストアイテム：テスト対象を構成する各要素。 通常、一つのテスト対象に対し、多数のテストアイテムがある。例えばECサイトの機能テストを行う場合、テキストボックスの「バリデーションチェック」、ボタン押下時の「画面遷移」、キーワード入力後の「検索処理」などがテストアイテムにあたる。
（※3）記述式テスト（スクリプトテスト）：設計書や仕様書といったドキュメントをもとにテスト設計を行い、テスト仕様書を作成した上で、実行者はテスト仕様書のテストケースにもとづいて実行するテスト
（※4）JSTQBシラバス：テスト技術者資格制度 Foundation Level シラバス Version 2018V3.1.J03
（※5）テストチャーター：テストの目的を完了したか判断するための指針