探索的テストがバグの大半を検出する
少し前にJaSST'13Tokyoに参加したのだけれど、そこでの基調講演で気になったのが、「システムテスト工程では、バグの半分は探索的テストのアプローチで検出される」という言及。その場で聞いたときは、手順のドキュメント管理が十分でない手法にバグ検出の大半を頼る体制に不安を覚えた。のだけれど、振り返ってよく考えてみると、結構自分の経験ともそんなに違わないなと感じた。
例えば自分がシステムテストでバグを見つける場合は、以下のようなパターンが少なくない。
- 手順に従ってテストしている最中に、期待結果に違反していないけれど、気になる症状や情報を見つける（例えばちょっと遅く感じたとか、手順が物足りないだとか）
- 手順の合間や空き時間にその気になる所を追っていくうちに、バグ遭遇
そのため、手順書非依存で見つけるバグが全体の半分を占めるといわれても、経験的にあまり違和感はない。
上記のパターンが多くなるのにはいくつか理由がある。自分の場合だと例えば以下の事情が大きいと感じている。
- 開発中の機能テストやスモークテストといった前段階のテストで、あからさまなバグはほとんど検出している。
- 手順の作成・保守コスト、実施テスト、対象の複雑さといった要因から、システムテストの網羅性や粒度はそんなに十分じゃない。
このようにわかりやすいバグがなくなっている一方で、テスト手順の網羅性が完璧でないならば、探索的テストの効果が相対的に高まるのも自然な傾向だと思う。
「半分」という数値は前後するかもしれないけれど、複雑なテスト対象を相手にしていて、事前テストを充実させている現場なら、これと似た傾向を示すんじゃないだろうか。
探索的テストの必要性を認識する
なおこうした傾向を持つならば、「探索的アプローチに支えてられている」「探索的テストを活用できる余地がかなりある」という状況下にあることを、きちんと認識すべきだと思う。具体的には、例えば以下の点に注意が必要だと感じる。
●探索的テストの前提知識を身につけさせておく
探索的テストはテスト対象をより理解しているほど、効率が向上する。
そのため例えばシステムテスト工程になって新しいテスターを入れるような状況は結構問題になる。そこでは慣れない最初の方は適切な探索的アプローチがとれず、手順から離れたバグを見逃す可能性を高める。
対策として、上流からドキュメントレビューに参加させたり、開発工程中も前倒しの機能テストを実施したりすることで、システムテスト開始時点でテストエンジニアに前提知識をつけさせておくと効果的だと言える。
●探索的テストの知見を共有する
例えば以下のような情報は、探索的テストでバグを探索していく上での知見として参考にできる。
- 類似プロジェクトでのバグの傾向やバグリスクの情報
- 前工程までのバグの傾向やリスク管理情報
こうした探索的テストの知見を共有できる体制をとっておけば、探索的テスターとしての技量が底上げされ、よりバグを効率的にピックアップできると感じる。
●手順に書かれないテストの必要性を認識する
見出しの通りだけれど、例えばテスト実行の自動化は注意が必要になる。自動化すると、怪しいところを感じ取って深追いするような、人間の知能を活かした探索的アプローチが弱くなり、バグ見逃しの可能性を高めるかもしれないからだ。自動化するなら、"手順そのままを自動化"でなく、網羅性を高めたり、慎重にテスト設計を行い品質リスクをよりカバーしたりして、探索的アプローチを補う工夫が必要だと思う。
またテストを進める上で、手順以外のテストも許容するべきだと思う。手順書通りにやるのは、正確性や再現性の面で必要だけれど、それでも手順書に書かれていない所を後から深追いしたり記録したりする心がけも推奨すべきだと思う。工数が増えるのを嫌がる等の理由で「手順以外余計な事をするな」なんて言っているのを見たことがあるが、危険な判断だと思う。
●プロセスの一活動に探索的テストを含ませる。
これも見出しの通りだけれど、そもそも論として、探索的テストをプロセスとして管理しながら毎回実施するのも重要だと思う。きちんとした手順にもとづいて探索的テストの戦略やチャータを設定し、ランドマークツアーやマニュアルベースのような手法活用の経験を積ませれば、各自の意志で実施する探索的アプローチの効果も高まっていくと思う。
