アドホックテストは宝探し

こんにちは、トーマです

本日はソフトウェアテストの技法の一つ「アドホックテスト」について書きたいと思います。

アドホックテストとは

アドホックad hoc)は、「特定の目的のための」「限定目的の」などといった意味のラテン語の語句です。
それをもじったこのテストは「特定の目的のために行われる、通常のテストプロセスとは別観点のテスト」と私は認識しています。
雑な言い方をすると「テストケースを使わずに、テスターの勘と経験を頼りにバグを見つめるためのテスト」ですね。

  • 探索的テスト
  • モンキーテスト
  • ゲリラテスト

など、様々な呼称がありますが、共通するのは「テストケースを作らない」という点です。
観点はテスターやそれを指揮する人に左右されます。

アドホックテストのメリット

色々ありますが、3つくらいご紹介します。なお、今回はWEBアプリケーションのテストを前提にしてみます。

①通常のテストでは検出できないバグを検出できる

通常、テストケースにはインプットとなる情報があります。多くの場合は設計書ですね。
当然ですが、プログラムの動作1つ1つを設計書に全て書くのは非現実的です。一方でユーザの操作パターンは無限に近いほどあります。

そういった設計書に記載しきれない点(=通常のテストケースではカバーできない点)を色々と試してみることで、新たなバグの検出につなげることができます。

特に、新規画面や新規項目を追加したときなど、あまり叩かれていない状態であればより効果的です。

②多角的にテストできる

冒頭に記載した通り、アドホックテストのカギは「テスターの勘と経験」です。これは人ごとにと異なります。
そのためテスターによって微妙に異なる観点でテストできる可能性が高く、バグの検出率の向上につながります。
殺虫剤のパラドックスをいい感じにケアできますね。

③時間の融通が利く

アドホックテストはその性質上、ちょっとした空き時間でもアサインがしやすいです。
そのため、プロジェクト内で空いてしまった工数を有効活用することができます。

アドホックテストの注意点

こちらも色々ありますが、長くなるため1つにします。

「目的をもって実施すること」です。

いい加減に操作するだけでは、検出できるバグは限られます。
「ここが怪しいから、こういう動作をさせてみてはどうか」と考えながら実施することが大切です。
テストを通じてテスターが学習し、より検出の難しいバグを検出していけるのが理想です。

たかがテストと侮らず、仮説検証を繰り返すことで、よりバグに近づけます。

そのためには、テストの方向性を示してあげることも大事です。
『 この画面を適当にいじってほしい』
ではなく
『 この画面のこの項目について、こういったパターンでの入力を試してほしい』
のようなイメージです。

まとめ

何かと便利なアドホックテストですが、考えなしに実施しないよう、注意が必要です。
個人的に「モンキーテスト」という表現は好きではありません。(サルのように考えずに実施する、という理解)

「探索的テスト」という表現もあるように、宝(=バグ)を探す一世一代の冒険のような気持ちで、テストに臨んでもらいたいと思います。