アドホックテスト（モンキーテスト）とは｜短期間・低コストで品質を底上げ

ソフトウェアテストの手法の１つに、アドホックテスト（モンキーテスト）と呼ばれるテストがあります。
アドホックテストの「アドホック」とは、ラテン語で「その場限りの」「特定の目的のための」といった意味をもち、場当たり的に思いついたテストを実施することを指します。

場当たり的・思いつきという言葉だけ見るとテストとして果たして役に立つのかと思われるかもしれませんが、むしろ場当たり的だからこそ発見できる不具合もあります。

また通常のソフトウェアテストと異なり、必ずしもテスト設計などの準備が必要なく即座に始めることもできることから、時間やコストに余裕がないときや、開発・テスト工程の終盤で品質の底上げに有効なテスト手法でもあります。

事前に必ずしもテストケースを準備する必要が無いという点で探索的テストと比較されることもあります。
探索的テストについては『探索的テストとは｜スピード×コストに優れるテストスタイル』の記事で紹介していますので、ぜひ合わせてご参照ください。

こちらの記事では、アドホックテスト（モンキーテスト）の利点や、実施におけるポイントについてご紹介します。

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

日本におけるソフトウェアテスト技術者資格認定の運営組織であるJSTQB（Japan Software Testing Qualifications Board）によれば、アドホックテストとは「公式なテストの準備をせず、非公式に実施するテスト」と定義されています。
通常のソフトウェアテストでは、テスト設計など事前にテスト実行のための準備を実施しますが、アドホックテストではそういった準備を省くことからテスト設計技法を用いず、またテストの結果にあたる期待値の設定や予測も行わないことから、テストのたびにテスト方法が変わるという特徴があります。

一般的にはアドホックテストは「場当たり的」「思いつき」で行うテストを指し、テストの対象や手順などを定めず、仕様についても確認を行わずに（あるいは必要最小限にとどめて）行うこともあります。
アドホックテストであっても人間のテスターが実施することから、実際は無秩序でランダムな操作というよりも、通常行わないような操作をあえて行ってみたり、バグが発生しそうな操作を意図的に繰り返してみたり、と何らかの目的や狙いをもって実施されることが多いといえます。

一方でモンキーテストとは、テスト対象のシステムの仕様やユースケースについては全く考慮せず、広範囲の選択肢から「ランダムに選択」し、ボタンを「ランダムに押す」ことでテストを行なう方法とJSTQBでは定義されています。
仕様や開発者の意図などを一切考慮せず、「何も知らない猿が操作をするようなテスト」のことを指すことから、モンキーテストと呼ばれます。

JSTQBではアドホックテストとモンキーテストは異なるテストとして区別されていますが、テストの場面ではほぼ同じ意味として用いられることが多く、「モンキーテスト」といった場合でも実際にはテスターが何らかの目的・意図をもって実施する（完全にランダムというわけではない）ことから、実態としてはアドホックテストと同様のテストをしているケースがほとんどと思われます。
ゆえに、ここではアドホックテストとモンキーテストを区別せず同義として用います。

SHIFT ASIAのアドホックテスト

アドホックテスト（モンキーテスト）の有効性

通常のソフトウェアテストで見つかりにくいバグを検出しやすい

アドホックテスト（モンキーテスト）は上記の通り、テスト設計を行わずに場当たり的にテストを行います。
通常のテストでは仕様をインプットにテスト技法を用いてテスト設計を行い、そのテスト設計仕様書に従ってテストを実行しますが、アドホックテスト（モンキーテスト）ではその場当たり性・ランダム性ゆえに、通常のテストでは発見しにくいバグを発見できることがあります。
なぜならば、設計書をベースとしたテストであっても全数テストは不可能であり、スコープ外の不具合は見つけることができません。

またどれだけ時間をかけて入念にテストを行ったとしても、設計書には書き起こせないような「特殊な手順」で発生するようなバグは検出ができないという理由もあります。
そもそも仕様に載っていないような操作を試したり、開発者の意図や想定と異なる操作をすることによって、それまでに検出されなかった重大なバグが見つかることもあります。

必ずしも準備が必要ではないことから、とにかく早い

ソフトウェアテストにおいて、テストの計画や設計、テスト対象の仕様やユースケースの理解といった準備には、実際にテストを行う「テスト実行」に比べ何倍もの時間がかかります。

しかしアドホックテスト（モンキーテスト）では、テストの目的に応じてケースバイケースではあるものの、準備にかかる時間は圧倒的に短いと言えます。
準備に時間がかからずすぐにテストの実行を開始できることから、特に時間やコストに余裕がない開発・テスト工程の終盤において「短期間」「低コスト」での品質の底上げに特に有効とされています。

アドホックテスト（モンキーテスト）における注意点

不具合を検出したとしても、再現が難しい場合がある

アドホックテスト（モンキーテスト）ではテスト設計仕様書を作成しないことから、通常のソフトウェアテストとは異なり、テストの実施記録を残さないことがほとんどです。

テスト実行の過程で都度記録をせずアドホックテストを行う場合、もし不具合を検出したとしても、手順の特殊さや複雑さによってその再現が難しい、あるいはできないというケースが発生することがあります。
再現手順を記録するためのツールなども存在しているものの、基本的にはテスター本人がある程度手順を記憶しながら進める必要があります。

テストを行ったとしても、品質の「評価」には活かしにくい

アドホックテスト（モンキーテスト）では場当たり性が極めて高いことから、テストを行ったとしても対象の機能の品質が「高そうだ」「低そうだ」という評価がしにくいというデメリットがあります。

通常のソフトウェアテストでは対象ごとに同様の技法を用いて粒度を揃えてテストを行うことから、機能ごとの品質の評価・比較や、「この機能に対してはこれらの観点・テストケースで不具合が生じないことを確認できた」という一定の「品質保証」が可能です。
一方アドホックテストではその場当たり性により、品質の「評価」や「比較」、「保証」には向きません。

ゆえに仮に特定の機能に対して、アドホックテストを徹底的に実施した結果不具合が検出されなかったとしても、対象の機能に対して「品質が良さそうだ」という判断はできません。

アドホックテスト（モンキーテスト）におけるポイント

アドホックテスト（モンキーテスト）は場当たり的なテストとされているものの、テストの目的や状況にもよりますが、多くの場合はアドホックテストの目的や範囲、観点などをある程度定めることが有効です。

例えば開発・テストの終盤において「残った時間・予算を使って、少しでも重大なバグの残存確度を下げたい」というシチュエーションであれば、重要な機能や過去に重大な不具合が発生した機能・あるいはその周辺の機能を対象とし、テスターは過去の不具合情報をインプットした上でアドホックテストを行うことが効果的です。

あるいは特に確認したい観点をアドホックテスト用のテスト観点として用いることで、例えばCRUDやバリデーションにフォーカスしてアドホックテストを行うことによって気になるポイントでの不具合を検出できる可能性が高まります。

実際にSHIFT ASIAのアドホックテスト（モンキーテスト）では、これまでの膨大なテストを通じて構築された標準観点をベースに作成された「アドホックテスト用のテスト観点」が存在し、多くの場合その観点を用いてアドホックテストを実施します。
それによって気になる観点を狙い撃ちすることができる上、特定の観点での品質の程度をある程度把握することも可能となります。

一方で、純粋に何も考えずまさに「猿」が操作をするようにテストを行った場合、仮に不具合が発生した場合でも再現が極めて難しくなることがあるため注意が必要です。

アドホックテスト（モンキーテスト）は、そのメリットとデメリット、実施におけるポイントを認識した上で実施することで、非常に有効に機能しうるテストです。
しかしながら、決して設計ベースのテストに取って代わるものではなく、補完的な関係であることをしっかりと理解した上で、双方のテストを組み合わせて実施することが非常に重要といえるでしょう。

SHIFT ASIAについて

我々SHIFT ASIAは、ソフトウェア品質保証・第三者検証のリーディングカンパニーである株式会社SHIFT（プライム市場上場）の海外戦略拠点として、ベトナム・ホーチミンでマニュアルテストからテスト自動化やセキュリティテスト、インスペクションなどのソフトウェアの品質保証事業を手掛けながら、近年はオフショア開発にも事業領域を拡大させてきました。

経済産業省が発表したレポートによると、日本では2025年にはIT人材の不足が約43万人まで拡大すると言われるなど、特にIT業界ではエンジニア不足が大きな問題になっています。
SHIFT ASIAでは、こうしたIT人材の不足を解決する手段として、海外の優秀なエンジニア層を取り込み、彼らのリソースを活用しながら日本のお客様のニーズに応えるべく、優秀なベトナム人エンジニアの採用と育成に力を入れています。