探索的テストとは

「探索的テスト」というワードを最近は各所で聞くようになってきました。

それが何か?というと、ざっくりこんな感じと思っています。↓

試験対象ソフトウェアを動かして得た情報や事前知識を元に、テスト設計とテスト実施を頭の中で順次並行で行う

一般的なテストのやり方が
①「どんなテストするかを考える」
②「手順や期待値をテストケース的なものに記述」
③「テストケース的なものに従ってテスト実施」
を順次やっていくのに対して、①~③をすべて「並行して実施」することが探索的テストと思っています。
そして、①と②は「アタマの中で実施」になります。
よってテストケース的なものは作成しません。

要は
「最初に全てのテスト内容を決めるのではなく、テストを実施しながらテスト対象の反応を見ながら次にやるテストを決めていく」
ということかなと。

「反応を見る」→「次のテストを決める」
ところがキーポイントと思います。
そして、「テスト設計は頭の中で実施している」こともポイントと思います。
この二点がないと、いわゆる「モンキーテスト」「フリーテスト」と変わらなくなります。

ですので、私の解釈としては、
「モンキー/フリーテストの進化版」
ではなくて
「ウォーターフォール的テストを特定の目的に向けたブラッシュアップ」
だと思っています。
「テスト設計」がキチンとできない人にはできない手法ですし、テスト設計ができない/したくない人の逃げ道には使えないと考えます。

効果は以下と考えます。
・インシデント発見におけるコストがスクリプトテスト(テストケースを作成するテスト)に対して低くなる
・使用性などの利用者観点のテストがスクリプトテストよりも実施しやすい

一般的な内容と思いますし、札幌チームでも導入事例がいくつかありますが、上記はおおよそ一致していると思っています。

もちろんデメリットも。
・テスト実施のエビデンスが残りづらい
・事前のテスト計画が抽象的になるので、レビューや合意が難しい
・網羅を目的とするテストには向かない

ということで、普通は網羅を目的としたスクリプトテストとのハイブリッドで使用することが
多いと思っています。

ちなみに、探索的テストの前提となる仮説は以下と考えています。
・インシデントが潜む箇所は偏在する
・テスターが発見するインシデントの多くは、実施中のインスピレーションに依存する
・テスト設計/項目作成の段階で、事前にインシデントが潜む箇所を特定する事は難しい

多分に個人的な仮説になりますが、テストを現場で担当する方はある程度同意いただける内容なのではないかと。

「バグってのは人目に付く場所にはいないんだぜ!」
と私も思っています。
探さないと見つけられません。
事前にアタリを付けてもそんなには的中しないし。

だからこその「探索」なのです。

「冒険」ではありません。
「探検」でもありません。
この二つは無謀さと無計画さを感じます。

「探索」=探りながら捜索
のポイントは以下と考えています。

・事前にある程度の計画をたてる
・ソフトとの「対話」による計画の修正と検討

個人的には音楽の「ジャズ」を感じます。
・ある程度の計画(曲のテーマメロディやコード進行)
・メンバとの対話(演奏者同士のコール&レスポンスによって曲を作っていく)

というわけで、札幌チームの取り組みや事例や集めた情報などをもとに、探索的テストについて今後は記事にしてみようと思います。

ちなみに、JSTQBのテストアナリストのシラバスを見ると、以下になっています。
「探索的テストには、テスト担当者がプロダクトとその欠陥の学習、完了すべきテスト作業の計画、テストの設計と実行、および結果の報告を同時に行うという特徴がある。テスト担当者は、テスト実行時にテスト目標を動的に調整し、軽量のドキュメントのみを準備する」(JSTQB-Syllabus.Advanced_TA_Version2012.J01より引用)

「動的に調整」がポイントですね。

これができ得るのは「ドキュメントの軽量化」「プロセスを同時に実行」を重視するからと思います。

アジャイル開発と相性が良いのは言うまでもないですね。