ソフトウェアテストにはテストケースを用意しないやり方として、アドホックテスト、モンキーテスト、探索的テストなどがあります。上手く活用すれば効率よくソフトウェアの品質を向上させられます。本記事ではそれぞれのテスト観点、目的、メリット、違いをご紹介します。テストケースを用意しない経験ベースのテスト手法を導入してみたいとお考えのソフト開発者関係者の方におすすめの記事です。
ソフトウェアテストの一種である「アドホックテスト」とは
ソフトウェアテストはテストベース（仕様書などテストケース作成に用いる情報源）をもとにテスト設計を行い、テストケースを作成するやり方（本記事では以降、スクリプトテストと呼びます）が一般的です。アドホックテストはこのようなプロセスを省きテストを実施します。そのため『非公式に実施するテスト。公式なテストの準備をせず、実績のあるテスト設計技法を用いず、テスト結果も予測せず、毎回、テスト方法が変わる。』とJSTQB用語集（ソフトウェアテスト標準用語集Version2.3.J01）で定義されています。
さまざまなアドホックテストの定義
一言に「アドホックテスト」といっても定義の仕方、位置付けは以下のようにさまざまです。
●スクリプトテスト以外のテストの総称
●後述するモンキーテストのようにテスト設計を考慮せず場当たり的に思いつきで実施するテスト
●テスト対象の仕様を理解している技術者がユースケースを考慮して、不具合が発生しそうな機能や設定、ユーザが誤操作しそうなオペレーションを意図的に確認するテスト
本記事ではアドホックテストを一定の仕様理解のある技術者が狙いをもって実施するテストと定義します。
モンキーテストとの違い
アドホックテストと似たテストのやり方にモンキーテストがあります。モンキーテストという名称は、仕様を全く理解していない猿にテストを実施させるという意味から名付けられています。JSTQB用語集（ソフトウェアテスト標準用語集Version2.3.J01）では、『製品の使用方法を全く考慮せずに広範囲の選択肢から「ランダムに選択」して、ボタンを「ランダムに押す」ことでテストを行なう方法』とされています。
ただし、モンキーテストも、アドホックテスト同様に複数の定義があります。
●テスト対象を一度も扱ったことのない人が実施するテスト
●通常のユースケースでは想定されないような操作をするテスト
●仕様上、関連のない機能を組み合わせて連続で操作するテスト
一般的に、アドホックテストは仕様を理解している技術者が実施します。例えば、何か値を設定するようなテストでは仕様を意識して設定可能な文字列のみを設定してテストを行います。一方、モンキーテストは仕様の理解がないため、設定する文字列も完全なランダム形式で行われます。
このようにアドホックテストとモンキーテストには違いがあるものの、実際にはどちらの方法も厳密には問題の起こりそうな操作を意図的に操作している側面があるため、アドホックテストとモンキーテストは同義に扱われることが多いのが現状です。
アドホックテストの効果と注意点
アドホックテストを導入した場合の効果と注意点を説明します。
限られた時間内で実施可能
スクリプトテストでは、テスト設計やテストケース、テスト手順の作成などに工数がかかります。一方、アドホックテストでは、こうした準備が不要のため、限られた時間内でいつでもテストができます。例えば、手が空いているメンバーが実施したり、スクリプトテストが早めに終了した場合に残りの期間で実施したりできます。このように時間を有効活用して、追加テストを実施することで不具合が見つかる場合もあります。
想定外の不具合を発見できる
仕様に載っていないような操作や開発者の意図と反する操作をテストすることで、過去に検出されなかった不具合が見つかる場合があります。ソフトウェアテストの７原則の１つに「全数テストは不可能」という原則があります。これは、「すべてをテストすること（入力と事前条件の全組み合わせ）は、ごく単純なソフトウェア以外では非現実的である。」という原則です。
このように、全て確認できないため、テストスコープ外に予期せぬ重大な不具合が残存することがあります。アドホックテストではこのような想定外の不具合を発見できることがあります。
品質の評価が難しい
アドホックテストには「品質の評価が難しい」という注意点があります。通常はあらかじめ組織で決められた品質指標に沿ったカバレッジ率を超えるようにテストをして品質評価をします。しかし、アドホックテストではカバレッジの正式な算出方法がないため、品質評価ができません。あくまでもアドホックテストは、スクリプトテストを補完するものであることを理解しておく必要があります。
エラー推測、探索的テストとは
アドホックテストに似たテスト方法として「エラー推測」と「探索的テスト」があります。これらは経験ベースのテスト技法としてJSTQBの公式シラバスに掲載されています。それぞれのテスト観点とメリット、デメリットをご紹介します。
エラー推測とは
エラー推測とはJSTQB用語集では、『テスト設計技法の一つ。テスト担当者の経験を駆使し、エラーが起きた場合にどのような欠陥がテスト対象のコンポーネントやシステムの中に存在するかを予想して、その欠陥を検出するテストケースを設計すること。』と定義されています。
例として、対象製品や類似製品で過去に起きた障害事例を分析して弱点になっていそうな機能を重点的にテストしたり、テスト担当者の過去の経験や知識を元に不具合を作り込みやすい設定値をテストしたりします。テスト担当者の経験を活かせる点がメリットです。デメリットとしては、カバレッジを評価することは困難であり、テスト結果がテスト担当者のスキル・経験に依存してしまうことがあげられます。
探索的テストとは
探索的テストはJSTQB用語集では、『非公式なテスト設計技法の一つ。テストを実施する過程で、テスト担当者がテスト実施情報を活用しながらテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する。』と定義されています。テスト対象を実際に動かし、理解を深めていきながら、テスト設計、実行、結果確認を行っていくことを指しています。探索的テストには以下のメリットがあります。
●テストケースを作成せずにテストを行うため、少ない工数でテスト可能
●テストを実施していくにつれてシステム理解が深まり、新たな気づきをテスト観点に反映するため、あらかじめ作成したテストケースでは見つけられなかった不具合を発見できる
●アジャイルソフトウェア開発のように短期間で開発を進めるケースでは柔軟かつ迅速にテスト可能
ただし、メリットだけでなく、以下のようなデメリットもあります。
●探索的テストだけでは品質確保はできない
●テスト設計書などドキュメントを作成しないため、テストのノウハウを蓄積しにくい
●テスト経験が豊富な人がテストする前提のため、経験が浅い人では実施することができない
さいごに
今回の記事でご紹介したテスト技法をISTQBの用語集でまとめると、以下のとおりです。
| 用語 | 定義 |
|---|---|
| アドホックテスト | 非公式に実施するテスト。公式なテストの準備をせず、実績のあるテスト設計技法を用いず、テスト結果も予測せず、毎回、テスト方法が変わる。 |
| モンキーテスト | 製品の使用法については全く考慮せず広範囲の入力からランダムに選択し、ボタンをランダムに押すことでテストを行なう方法 |
| エラー推測 | テスト設計技法の一つ。テスト担当者の経験を駆使し、エラーが起きた場合にどのような欠陥がテスト対象のコンポーネントやシステムの中に存在するかを予想して、その欠陥を検出するテストケースを設計すること。 |
| 探索的テスト | 非公式なテスト設計技法の一つ。テストを実施する過程で、テスト担当者がテスト実施情報を活用しながらテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する。 |
いずれの方法もスクリプトテストとはテスト方法が異なるため、予期せぬ不具合を発見できたり、少ない工数でテストができたりといったメリットがあります。しかし、品質評価ができない、テスト設計書等を作成しないため、ノウハウを蓄積しにくいといったデメリットがあります。
今回紹介したアドホックテストはテスト対象全てを確認するのは不可能だからこそ、実施する価値があります。しかし、テスターの経験に依存するテストのため、適切な人材を選ばないと、いくら工数をかけてテストを実施してもプロダクト品質向上につながりません。そのため、効率的かつ効果的にソフトウェアテストで品質を向上させたい場合は専門家に相談すると良いでしょう。
参考：
テスト技術者資格制度 Foundation Level シラバス Version 2018V3.1.J03
http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
