探索的テストとスクリプトテストを対比するのはミスリードかもしれない。#JaSSTOnline

　JaSST Onlineで、ネモさんの探索的テストセッションを観ました。

jasst.jp

　他の人の探索的テストを見る機会ってあまりないので、とてもよいですね！ ネモさんの思考の過程を見るのも楽しいし、他の参加者の方が発想を次々に投げ込んでくるのもとても良い。面白いセッションでした。オンラインの不自由さを逆手に取った企画で、とても好きです。

　さて、今日のポエムです。
　思いつきの吐き出しに過ぎないので、箸休めと思ってください。

テストの2つの目的

　以前、ISTQBで定義されている「テストの目的」について書きました。

www.kzsuzuki.com

　今では7個もあってなかなかややこしいのですが、わかりやすいのは、「バグを見つけること」と、「品質の程度を把握すること」の2つだと思います。記事の最後にある2011年版の記述でいうと、それぞれ「Finding defects」と「Gaining confidence about the level of quality」ですね。本記事ではそれぞれ、目的A・目的Bと呼びます。

　この両者でわたしが重きを置いているのは目的B、「品質の程度を把握すること」。
　これがこの記事の大前提で、バイアスかかっていることをお含みください。

　さて、目的A「バグを見つける」と、目的B「品質を把握する」で、テストはどう違ってくるでしょうか。
　端的に言うと、前者は「リスクの高いところ、怪しいところを狭く深く狙う」。後者は「提供する機能すべてを、広く浅く拾う」。 ってことじゃないですかね。
　もちろん前者であっても、ある部分は少しもテストをしないということはないでしょうし、後者であってもリスクに応じた重みづけはするので、あくまで傾向です。

テストの目的と探索的テスト

　探索的テストって、前者の目的A、つまりバグを狙っていくことを押し出したスタイルですよね。
　対象のソフトウェアを触りながら怪しいふるまいのしっぽをつかんで、そこを攻めていって、バグを叩き出す。 これは価値のある成果だと思います。

　一方、後者の目的B、品質を把握するという観点から見ると、どうでしょう。

　探索的テストはしばしば、成果の説明が難しいと言われますが、その理由は「システマティックでない（ように見える）ため、何を保証しているかの説明が難しい」ということだと思います。たくさんバグを検出するという目的Aを果たせても、目的Bについてうまく語れない。

　では、目的Bから見た探索的テストの価値とは何でしょうか。
　いくつかあるとは思いますが、重要な一つとして「テスト観点の導出」があるでしょう。
　仕様書や、devチームとの会話からでは得られなかった、実物を触ったからこそ得られたインスピレーション、テスト観点。

　探索的テストのセッションの時間は限定的です。思いついた観点すべてを、セッションの中では消化しきれません。むしろ、実際にやれたことより、新しく追加された「やりたいこと」の方が多いかもしれません。
　セッションが終わったら、新しく得られた観点をできるだけ網羅できるようにテスト設計を行い、テストケースとしてテストセットにフィードバックしていく*1。これを、evolvable test design（進化可能なテスト設計）と呼びます*2。

　目的Bに観点に立つと、品質把握の精度を上げるための観点が得られたことの方が収穫で、バグを見つけたことはその過程での（嬉しい）副産物、という位置づけだと捉えることもできるのではないでしょうか。極端かしら。

探索的テストとスクリプトテスト

　ところで、探索的テスト以外の「普通の」スクリプトテスト（scripted test、手順のあるテスト）で、こういうことってしないでしょうか。そんなことないですよね。

　わたしのチームでは、あるテストケースを実行した際に気の付いた点、別途確認したいと感じたことを書き残すようにしています。ですので、テストケース1件を消化したら、0.5件分の潜在的テストケース*3が生まれているような感じになります。
　その意味では、スクリプトテストでも、探索的テストを同じことをしているんですよね。
　つまりこの視点では、手順の有り無しは本質的じゃあない。

　じゃあ何が違うか。
　違いは、テスト実行中に観点を見つけるために通れる道の多さ、なんじゃないですかね。

　スクリプトテストの書き方・粒度はいろいろありますけれど、インプットと期待するアウトプットはまあ、決まってますよね。通れる道は、1本。せいぜい2～3本でしょうか。
　探索的テストは、何をインプットするかはその場で決まります。すると、選べる道はかなり増えます。増えすぎるとワケがわからなくなるので、チャーターで「方向」は決める。ある方向に向かう道は、それでも何本もあるので、いろんな道でいろんな気づきを得られる。
　いわゆるモンキーテストは、その方向もゴールも何もないので、運がよければ気づきを得られるでしょうけれど、同じ場所をぐるぐる回っているだけかもしれない。

　目的Bの観点では、探索的テストの「選べる道の、ほどよい多さ」が、テストとしての価値につながるのではないか、と思いました。

まとめ

　まとめます。

• テストの目的として、「バグを見つける」と「品質を把握する」がある。
• 「バグを見つける」目的は、怪しい箇所を素早く狙っていく探索的テストが有効に働きやすい。
• 「品質を把握する」目的に対して、探索的テストは特定のエリアのテスト観点の導出につなげることができる。
• スクリプトテストにおいても観点の導出は行うので、本質的に違いがあるわけではない。

*1:これがオーソドックスなやり方かのように書いていますが、わたしのやり方がこうだというだけです。

*2:呼びません、カッコいい名前つけたかっただけです。evolutional より evolvable の方がかっこよさげに感じただけです。

*3:potential test case、もちろん造語です。