自動テストと探索的テスト
探索的テストは、テスト設計やテスト実装を事前に行った上で実行する「普通の」テスト（「スクリプトテスト」と呼ばれることもあります）とは対照的に、人間がソフトウェアの反応を見ながらその場で次の手を決めていき、ソフトウェアの怪しい場所を探っていくスタイル[4]です。現在のところ、機械にお任せするのが難しいものと言えるでしょう。
書籍『実践アジャイルテスト』では、機能テストが第2象限（ビジネス面×チームを支援する）で「自動と手動」とされているのに対し、探索的テストは第3象限（ビジネス面×製品を批評する」で「手動」と明確に位置付けられています（下図）。
実はギア本においても、「探索的テスト」という言葉こそ使ってはいないものの、テストエンジニアの経験と直感に基づくテストを勧める記述がちらほら見られます。自動化を追求している著者らだからこそ、自動化では見つけることが困難なソフトウェアの欠陥をも熟知しているのだと思います。
自動化しやすいテストの特性を挙げるとすると、たとえば、
- 手順と期待結果が確立されており
- 欠陥が少ないはずであり
- それだけに退屈である
といったものがありますが、探索的テストはまさにその正反対です。手順と期待結果はその場で判断され、欠陥を狙うように進め、それだけに刺激的。テストエンジニアは、こういうテストこそ手動でがんばりたいものです。
ギア本のキャッチフレーズは、「退屈なテストにさようなら！」。退屈なテストとの縁は簡単に切れるものではありませんが、できるだけ距離をおき、「刺激的なテストにこんにちは！」と言えるよう、自動化を進めていきたいものですね。
[4] 探索的テスト（exploratory testing）は、JSTQBの用語集で「非公式なテスト設計技法の1つ。テストを実施する過程で、テスト担当者がテスト実施情報を活用しながらテスト設計をコントロールし、積極的に質の高い新しいテストケースを設計する」と定義されており、場当たり的にソフトウェアを動かしてみる「モンキーテスト」と一線を画しています。
おわりに
本書の発売以降、ブログやSNSを通して感想を書いてくださったり、読書会が催されたりしているのを見て、大変嬉しく感じております。
現在の状況から見て本書は、必ずしも完璧な「ガイド」ではないかもしれません。しかし、何かを議論する際に、議論のベースがあるのとないのではまったく違います。自動化のあるべき姿、ベストプラクティスについての議論を深めるための一助として本書を役立てていただければ、訳者としてこれほど幸せなことはありません。
