探索的テストの試行

[最終更新] 2019年6月22日

ギリギリの時間で開発していると、どうしてもテストが疎かになりがちであるけれど、だからといってバグが許容されるかというとそんなことはもちろんないわけで。しかし、実際のところバグはボロボロ出てくるもので、その時はやはり「テストしないといけませんね」という当たり前の結論になるのだが、そんなことはそもそもわかっていたことであって、それにも関わらずリリースに踏み切らねばならない状況だったことに問題の本質がある。そして今日も本質は放置されたままである。

とはいえ、短い時間でもどうにかできんものだろうか、ということで探索的テストについて調べた。

探索的テスト（Exploratory Testing）について

テストといえば、たいていはIEEE829に基づいてテストケースを記述して、ちまちま実行する…というような流れと思うのだが、それとは別に、テストケースを記述しないテスト手法というのもある。

探索的テストと呼ばれるもので、対象となるソフトウェアについてよく理解している成熟したテスターが、テスト設計して実行し、その結果に基づいてさらにテスト設計、実行……と繰り返していく。

必ずしもテストケースを記述するわけではないが、ちゃんと設計するし、仮設をたてて検証し、結果に基づいてさらなるアクションを行うわけで、いわゆるランダムテストではない。

なんとなく、流れそのものにアジャイル開発っぽい印象を受ける。うまくやれば、短い時間で結果を残すことができる…ようだが、一番のネックは成熟したテスターって誰や、というところではなかろうか。少なくとも私ではない 笑。まぁそんなこと言ってられないのであるが。。。

この手法を知ったのは「知識ゼロから学ぶソフトウェアテスト」という書籍からだ。著者の修士指導にあたったのが、探索的テストの提唱者であるCem Kanerらしく、書籍でも探索的テストをしない理由はないとまで書かれている（ただし、非機能要件については、ユーザビリティ以外成果は芳しくないらしい）。

それが本当に知識ゼロの一読者でも良いのかどうかはわからないが、なかなか楽しいと思えないテストの中でかなり興味を惹かれた手法であるので、部分的にも取り入れていきたい。

やり方

先の書籍によると、探索的テストはまず判定基準（クライテリア）を決めるとある。たとえば機能性、安定性について、pass基準、fail基準を設ける。そのうえでタスクを実行するのだが、タスク実行は以下の5つに分けられるとある。

1. ターゲットソフトウェアを決める（Identify the purpose of the product）
2. 機能をリストアップする（Identify functions）
3. 弱いエリアを見つける（Identify areas of potential instability）
4. 各機能のテスト及びバグの記録（Test each function and record problems）
5. 継続的なテストの実行（Design and record a consistencyverification test）

弱いエリアを見つける、が腕の見せ所だろうか。

やってみて

まぁこういうのはうだうだ勉強するより実践だろうということで、見よう見まねで開発中の機能についてやってみたところ、早速記述式テストで見つからなかったバグが見つかったので、効果がある…のかもしれない。しかもテストした機能で見つかったバグだけれど、バグそのものは別の機能の実装の時のものという、アレな感じ。

自分は明らかに熟練のテスターではないけれど、製品仕様について熟知していたし、ソースコードもだいたい検討ついていて、データベースを把握していたので、危なそうなところはわかっていた。また、データベースをいじったりツールを書いたりはできるので、だいたいのケースは実現できる。それで、今回はうまくいった（バグがみつかってうまくいったというのも変な話だが）、のかも。

アプリケーション内部のことがわかる開発者にとっては、やりやすいテスト手法に思えた。ウィークポイントを考えて仮説検証するのも、そこそこ楽しい。少なくともテストケースを書くより楽しい。その意味でも開発者向けのテストのように思える。

ただ、どうしても網羅的ではない。となると、これだけでは安心できないのもそうだろう。また、前述のように非機能要件についてはユーザビリティ以外難しいようだし。テスターの技量に大きく依存する点についても、自分でやる分にはだからこそ面白いというところだが、人に任せるとなると、まぁ考えるところはあるだろうなぁ。

ひとまず、続けてみようと思う。

関連記事

スポンサーリンク