2021.6.7

【第2回】：探索的テストのメリット・デメリット

ユーザーのニーズは年々多様化しており、システムの機能や動作もより高いレベルが求められるようになりつつあります。高度なシステムを実現する上でプログラムの複雑化は避けて通れず、当然ながらテスト工程にも相当な工数が必要です。

とはいえ開発スパンの短い現代の開発現場では、テスト工程に十分な工数を確保することはますます困難に。この課題に対する解決策として特に有力なものが、「探索的テスト」です。探索的テストは、テスターの知見を活用しつつテスト設計とテスト実行を並行するテスト技法で、テストケースの作成が不要となるなどテスト準備段階の工数削減において高い成果が期待できます。

ただし、探索的テストにもメリット・デメリットが存在し、効果的な適用を実現する上でこれらに対する理解が欠かせません。そこで、探索的テストの連載第2回である本記事では、探索的テストのメリット・デメリットについてご紹介しましょう。なお、探索的テストの基本的な知識については、まずは連載第1回の記事をご一読ください。

今こそ求められる探索的テストとは？　【第1回】：探索的テストの基礎知識

探索的テストの適用による3つのメリット

開発の現場ではテストの計画や設計を行い、それらをもとに実行する「記述式テスト (スクリプトテスト)」が良く用いられます。しかし記述式テストでは、計画や設計に費やす工数がテスト全体のスケジュールを圧迫することも珍しくありません。

結果として、限られた期間の中で膨大なテスト項目を実行しなければならず、高い成果が得られにくいなどの課題があります。探索的テストが持つメリットは、このような記述式テストが抱える課題を解決する上で、非常に有効です。まずは、探索的テストの適用により得られる3つのメリットについて、解説します。

メリット1：テスト工数の削減につながる

記述式テストにおけるテスト設計プロセスでは、システムの動作に影響しうる要素に関して漏れのない考慮が必要です。しかし、OSやブラウザといった全ての要素を掛け合わせるとテスト項目数は膨大なものとなり、テスト仕様書作成のために多くの工数が必要となります。
その点、探索的テストではテスト仕様書を事前に作成する必要がなく、費用対効果の低い冗長なテスト項目も省略可能です。結果としてバグ検出にフォーカスしつつ効率的にテストを実行でき、テスト工数の大幅な削減と短い開発サイクルを繰り返すアジャイル開発の実現などにつながります。

メリット2：記述式テストでは想定できないバグも検出可能

記述式テストでは掛け算式に大量のテスト項目を作成しますが、その大半はバグ検出の見込みが少ないテスト項目です。また、機能や画面ごとに異なるバグの発生リスクが考慮されないことも多く、平坦なテスト項目によって高リスクな箇所のバグを見逃す恐れもあります。
一方、探索的テストの場合はシステムの特性やテスト結果を考慮しつつ、高リスクな箇所を重点的にテストします。そのため効率的にバグを検出できるだけでなく、パターン化されたテストでは検知できない不具合を発見できるなど、記述式テストで見逃しやすいバグも検出できるのも大きなメリットです。

メリット3：仕様書や設計書に依存せず実施可能

記述式テストで適切なテスト設計を行うためには、仕様書や設計書といった開発ドキュメントが必要不可欠です。しかし実際は、このようなドキュメントが存在しなかったり、記述内容が不十分だったりすることも少なくありません。
その点、探索的テストの場合はテスト仕様書自体をインプットとしないため、仕様書や設計書が不十分であっても実施可能です。上流工程の作業品質に影響されることなく、テストでの成果を上げやすいのもメリットといえます。

探索的テストが抱える3つのデメリット

当然ながら、探索的テストにはデメリットも存在します。ここでは、3つのデメリットについて解説します。

デメリット1：テスターの経験やスキルに強く依存する

記述式テストであれば、テスト設計レビューで事前にフィードバックを受けた上でテストを実行できます。また、事前に作成したテスト仕様書に基づいてテストを実行するため、経験の少ないテスターでも実行上の問題はありません。
しかし探索的テストではテスターが独断でテスト項目を選定していくため、その成否はテスターの経験やスキルに強く依存するのです。バグの発生リスクが高い箇所を見極められずテストが特定分野に偏ってしまうと、費用対効果の低いテスト項目に多くの工数を費やす上に、バグの検出漏れも発生しやすくなります。

デメリット2：テスト自体の品質を保証するのが難しい

記述式テストのような掛け算式のテスト設計であれば網羅性が分かりやすく、テスト仕様書がその証左となります。しかし、探索的テストではバグ検出が優先されるあまり、実行したテスト項目すら記録されないことも少なくありません。そのためテスト仕様書からは網羅性を判断できず、テスト項目に漏れがないことを証明できないのです。
また、探索的テストでは事前にテスト手順や前提条件などが定義されないため、有用なエビデンスを残すことが難しいといえます。たとえログや画面キャプチャを保存しても、実際に正しい手順や前提条件のもとで実行されたのか、証明するのは容易ではありません。このように、探索的テストでは網羅性や実施内容の妥当性を証明するのが難しいというデメリットがあります。

デメリット3：関係者によるフィードバックが困難

探索的テストでは事前にテスト設計レビューがないため、テストに関する認識合わせが不十分なまま開始されることも少なくありません。テスターが仕様を正しく認識していなかった場合、実行したテスト内容自体が無意味となってしまい、大きな手戻りとなる恐れもあります。
また、テスト計画も明確に定義されないことが多く、管理者が進め方についてフィードバックすることも困難です。このように、探索的テストではテスターの判断にゆだねられる要素が多く、プロジェクト関係者がフィードバックしづらいというデメリットがあります。

この他にも、一般に探索的テストはレスポンスのスピードやセキュリティ、ユーザビリティ、メンテナンス性など非機能要件の品質検証には不向きと言われています。