「探索的テスト」はテスト方法の1種です。
開発期間が短いなどの理由で、テストを行ううえで欠かせないテスト設計やテストケースを準備できなかった場合に有効な方法だといわれています。

この記事では、ソフトウェア開発を行っている方に、探索的テストの概要や種類、各テストとの違い、メリット・デメリットなどを解説しています。

開発業務に携わっている・携わりたいという方は、探索的テストの概要について理解して、今後のソフトウェア開発に役立ててください。

探索的テストとは?

探索的テストとは?

探索的テスト(Exploratory Testing)とは、ソフトウェアテストの1種です。
テストケースを事前に設計せず、実行過程や結果に応じて、都度ケースを改善・新規設計していく方法のことをいいます。

テストを行いながら設計していくため、テスト前に設計や仕様書などを準備する必要がありません。

そのため、仕様書や設計書の準備時間を削減でき、素早くはじめられるのが、探索的テストの特徴です。テストの実行過程や結果をもとに内容を改善することから、対話型アプローチとも呼ばれています。

近年、探索的テストが注目されはじめた背景にあるのが、アジャイン開発です。
アジャイン(素早い)開発とは、大きな単位ではなく、小さな単位で実装とテストを繰り返して開発を行うプロジェクト開発手法で、従来の開発手法よりも開発期間を短縮することができます。

開発期間を短縮できることから近年、取り入られるケースが増えている開発手法です。
小さい単位で実装とテストを繰り返すアジャイン開発と探索的テストは相性が良いため、セットで取り入れられており、アジャイン開発の普及にともなって注目を浴びています。

スクリプトテストとの違いは?

スクリプト(記述式)テストとは、テスト設計にもとづいた仕様書を作成し、仕様書に沿って行うテストです。

仕様書に沿って行うため、スキル関係なく、確実に行えることができます。しかし、仕様書を作成するための時間やコストがかかるため、すぐに行うことができません。

仕様書を必要とせずすぐにテストをはじめられる探索的テストとは、まったく逆の立場にあるものといえるでしょう。

モンキーテストやアドホックテストとの違いは?

ここでは、モンキーテストやアドホックテストとの違いについて紹介します。
両者を解説するうえで欠かせないのが、「JSTQB」です。

JSTQBとは、日本のソフトウェアテスト技術者資格認定の運営組織で、JSTQBがモンキーテストやアドホックテストを定義しています。

JSTQBの定義によれば、モンキーテストは確認するシステム決めないで、選択肢の中からランダムに選択し、ランダムにボタンを行う方法です。何もわからないサルが操作するという意味から、モンキーテストと名づけられました。

アドホックテストは、公式に準備をすることなく、非公式で行うテストであるということをJSTQBは定義しており、場当たり的に行われる方法です。
場当たり的といわれていますが、普通なら行わない操作やバグが起きそうな操作を連続して行うなど、目的を持って行われるケースが多いです。

モンキーテストもアドホックテストも特定の目的またはランダム操作によって行われます。しかし、探索的テストはテストの過程や結果に応じて、内容や目標を改善していくため、内容や目標を随時改善するかどうかが、大きな違いといえるでしょう。

探索的テストの種類

探索的テストの種類

探索的テストの種類は大きく分けて、下記の3つです。

  • テストチャーターを用いる探索的テスト
  • セッションベースドテスト
  • フリースタイルの探索的テスト

ここでは、各種類について詳しく説明します。

テストチャーターを用いる探索的テスト

「テストチャーターを用いる探索的テスト」とは、テストの目的と目的が達成されているか判断する基準を設定したうえでテストを行う手法です。
テストチャーターとは、目的が達成されているか判断する基準のことをいいます。

セキュリティのトラブル事例などを参考にしながら、テストチャーターを設定し、バグやシステムエラーがないかチェックしていきます。

注意点としては細かく達成基準を設定しないことです。
仕様書に記載されているような細かく具体的な基準にしてしまうと、スクリプトテストとなってしまうため、抽象的な表現に留めておき、細かく設定しないでください。

セッションベースドテスト

「セッションベースドテスト」とは、実施セッション(単位)を一定時間に区切り、区切ったセッションごとに、テスト目的とテストチャーターを設定してテストを行う手法です。

一定時間ごとに区切って細かくテストするため、範囲を絞って余すことなく挙動などを確認できます。

フリースタイルの探索的テスト

「フリースタイルの探索的テスト」とは、テスト実施者の経験や考えにもとづいて行われるテストで、目的やテストチャーターは設定されません。

設定されていない分、柔軟性が高く、テストの過程や結果にもとづきながら方向性を修正できます。柔軟性が求められる分、実施者の依存度が高くなるため、経験や知見、バグが起きやすい傾向が分かっている方を実施者に抜擢しないと、効果的に行うことができません。

探索的テストのメリット

探索的テストのメリット

探索的テストのメリットは大きく分けて、以下の4つです。

  • スピードの速さ
  • 工数・コストを抑えやすい
  • 記述式テストでは検出困難なバグを見つけやすい
  • 様書や設計書に依存せず実施可能

仕様書などを細かく設定する必要がない探索的テストにどのようなメリットがあるのか気になる方も多いでしょう。

ここでは、各メリットをそれぞれ詳しく説明します。

スピードの速さ

探索的テストであれば、スピーディーにテストを進められます。
スクリプトテスト違って、事前にテストケースを準備する必要がありません。

そのため、ケースの設計や修正などの工程を省くことができます。
ケースの設計や修正といった準備工程はテストを行う以上に時間と労力がかかることも多く、これらの工程を省くことができれば、スピーディーにテストを進められるでしょう。

工数・コストを抑えやすい

工数・コストを抑えやすいのも探索的テストの特徴です。
事前にケースを準備する必要がないためケースの設定や修正などの工程を省くことができます。

仮にテスト設計が必要だとしても、最低限の準備でテストの実施・改善を行えることから、テストケースを作り込む必要がありません。

そのため、スクリプトテストと比較して、工数・コストを抑えてテストを行えます。
また、実行者個人で行っていくため、コミュニケーションコストを抑えることも可能です。

記述式テストでは検出困難なバグを見つけやすい

探索的テストであれば、記述式テストでは検出困難なバグも見つけやすいです。
過程や結果にもとづいて、テストケースを新規設計しながら、テストを行います。

そのため、テストケースでは想定できないような部分も確認することができ、スクリプトテストでは検出困難なバグも見つけやすいです。

仕様書や設計書に依存せず実施可能

探索的テストは仕様書や設計書がない場合や不十分な場合でも、ドキュメントに依存せずに実施できる柔軟性の高いテストです。

ソフトウェアテストの国際的な資格認定団体であるISTQBによれば、仕様書や設計書がない場合や不十分な場合に最も効果が期待できるテストであると述べています。

アジャイン開発は仕様書や設計書がない、あっても不十分なケースが多いです。アジャイン開発のデメリットを補えることも、両者の相性が良い理由といえるでしょう。

探索的テストのデメリット

探索的テストのデメリット

探索的テストのデメリットは大きく分けて、以下の3つです。

  • 属人化しやすい
  • 品質担保ができない
  • 管理・コントロールがしづらい

メリットだけではなくもちろん、デメリットも存在します。上手に運用していくためには、デメリットもしっかりと理解しておかなければなりません。

ここでは、各デメリットを詳しく説明します。

属人化しやすい

属人化しやすいのがデメリットです。
属人化とは、ある仕事の進め方や進捗状況を特定の担当者しか把握していないことをいいます。

探索的テストは個人で行うテストのため、テスト実施者のスキルや経験に依存する傾向にあり、作業スピードに個人差があったり、進捗状況の把握がしずらく属人化しやすいです。

品質担保ができない

探索的テストはテスト結果の品質を担保することができません。
仕様書や設計書が作成されない場合が多いのはもちろん、作成されたとしてもどのようにテストを進めていくか明確に設定されていないケースも多いです。

そのため、テスト結果の品質を担保できないつまり、品質を保証することができません。
品質を担保したい場合は、スクリプトテストも組わせることが大切です。

管理・コントロールがしづらい

探索的テストはテスト計画や設計が設定されないため、管理・コントロールがしづらいです。テスト実施者に委ねないといけないため、属人化しやすいのが、管理者が管理・コントロールしづらい原因です。

デメリットを解決するためには、スクリプトテストなど様々な種類のテストを使い分けたり、組み合わせたりすることが大切です。

【まとめ】探索的テストを理解・活用しよう

【まとめ】探索的テストを理解・活用しよう

仕様書や設計書に依存しない探索的テストを活用できれば、工数・コストを抑えながら、スピーディーにテストを行えます。

発注過多やIT業界の人手不足が深刻化している現代においては、開発業務を効率化してくれるテスト方法だといえるでしょう。

本記事のポイントは、下記のとおりです。

  1. 仕様書や設計書やなかったり、不十分だったりしても柔軟性の高いテストを行える
  2. 仕様書や設計書の作成工程を省けるため、コストや期間を短縮できる
  3. スクリプトテストなど様々なテストを組み合わすことでテストの質を高められる

効率よく開発を進めたいと考えている方は、探索的テストを上手に取り入れながら、スピーディーにソフトウェアテストを行ってください。