読書メモ。2025年24冊目。
『探索的テストの考え方 ソフトウェア開発のテスト設計とテクニック』を読んでの感想となります。（2025/3/24記載）
本の概要
探索的テストとはテストケースを作成せずソフトウェアを動作させながら進めるテスト手法です。手動テスト、スモール探索的テスト、ラージ探索的テスト（ツーリングテスト）、ハイブリッド探索的テスト、探索的テストの実践と話を広げ、また探索的テストの未来、テスト技術者としてのキャリアを成功させる方法をアドバイスします。
コンピュータを使ったことがある人なら誰でもソフトウェアに不具合があることは理解しているでしょう。 世界最初のプログラムから最新のアプリケーションまでソフトウェアが完璧であったことはなく、今後も完璧になることはないことでしょう。しかし現在社会は高品質のソフトウェアを必要としています。
実際にバグのあるソフトウェアがリリースされてしまっていますが、なぜコードレビュー、単体テスト、静的解析、その他の活動で発見されなかったのでしょうか？ リリース前にバグを発見する最善策とはどのようなものでしょうか？ これはソフトウェア開発者だけの課題でないことは明白で、バグの本質を理解するためには「テスト技術者」が最前線に出る必要があります。
本書はソフトウェアのテスト技術者向けに書かれたものですが、こうした課題を取り上げていきます。
引用：
動機
- アジャイル開発における探索的テストの重要性を聞いて久しい。
- モンキーテストやアドホックテストとの違いなどざっくり知っているがざっくり過ぎて実用には足りない。
- それ専用の本が出たのでちゃんと学びたい！！！
感想
探索的テストについて解像度をあげた理解を深めることができました。
この本を読むまで、探索的テストとは、単体テスト、結合テスト、総合テスト、受入テストなどの延長線上（もしくは同じ粒度）に存在するテストだと思っていました。
この本を読むことで、探索的テストとは濃度や程度の話でもあり、自分が今まで知っていたテストのなかに反映することのできるテストだと理解しました。
結合テストについて、今までシステムが振る舞うはずの動作を事細かに定義（再定義）し、その通り動くかどうかを確認していました。
それに対し、【事細かに定義（再定義）】すべきか判断し、必要と判断した場合にのみ実施することがスモール探索的テストであると理解しました。
また、総合テストとして今までに定義されたラインナップをただ実施するのではなく、どこに弱みがありそうかを判断し必要なアプローチを取ることがラージ探索的テストであるとも理解しました。
特にテストのアプローチを考えるうえで、ツアーというメタファーは効果的で、チームの共通言語として覚え、必要に応じて採択できると機能するイメージが持てました。
ただ、覚えるまでが大変そうで、他に変わるメタファーはないだろうかと考えてもパッとは浮かばない。
テストがアクティビティであることを考えると目的を持って行動を伴うものが良いんじゃなかろうかと思うけど、サブスク配信…とか？（YouTube型とかNetflix型とかSpotify型とか…）
そうした意味で、チームとして探索的テストを機能させるのには、一定のハードルがあるとも感じました。
また、そうしたハードルがあることを考えても、探索的テスト的なアプローチをもっと開発のはじめの頃に実施できないか、と考えています。
自分が想定しているテスターが開発者でもあることを考えると、テスターが実施する場合との違いは考慮したほうが良いのかも。
いずれにせよ、意図して状況に応じて能動的にテストを実施するスタイルは、自己組織化が求められるチームに親和性高そうです。
この本が出版されたのは2009年なので、今読むと古いと感じる部分もあります。
ただ、改めてテストについて学ぶところも多くありました。
著者であるウィテカーさんのJaSSTでの講演が楽しみです。
忘れたくないメモ
■テスト技術者の姿勢
テスト技術者の姿勢「どうすればアプリケーションを壊せるか」。開発者の姿勢「どうすればアプリケーションを構築できるか」。不具合を検出するためには開発者のパイアスにとらわれない新鮮な視点が欠かせない。
■ビジネスロジックのテスト
ビジネスロジックとはユーザー要求が実装されたコードであり、顧客がソフトウェアを購入する契機となるコード。
複雑なため、正しさを検証するタスクには人の介在が求められる。
結果、バグを発見するためには手動テストが最善の方法となり、多くの場合自動テストは向いていない。
■手動テストに求められる姿
高い目的意識をもって、定められた規則にのっとって行われる探索的テストプロセスを目指す。
手動テストは入念な準備が必要だが、テスト中にテスト技術者が意思決定を行う余地の残るプロセス。
■柔軟なテストを可能にするスクリプト
スクリプト手動テストはテスト手順が厳格すぎることがある。あるいは、厳格ではない運用がされることもある。
すべての入力手順を細かく文書化するのではなく一般的なユーザーシナリオとしてスクリプトを記述すれば、テスト技術者はある程度柔軟にテストを実行できる。
■探索的テストの２種類のガイダンス
探索的テストには2種類のガイダンスがある。
テストを実行する際に局所的な決定を支援する「スモール探索的テスト」。
テスト技術者が探索的テスト手法を使って入力値を決定する。
テスト技術者が全体的なテスト計画と戦略を決定するのを支援する「ラージ探索的テスト」。
特定の機能のテスト方法ではなく、アプリケーションをどのように探索するのかを導く。
■ソフトウェアテストのゴール
ソフトウェアのテストのゴールは、未テストの部分に大きな問題がないと自信を持てる状態を作ること。
これが達成できれば早期リリースのリスクを最小限に抑えることができる。
■入力の２つの分類
入力は原子入力と抽象入力の2つに分類される。
ボタンのクリック、文字列、整数値の4などは原子入力。それぞれ独立し、1つのイベントになる。
整数値など幅を持った抽象入力として扱うことで、ひとまとまりで理解できるようになり、推測が容易になる。
■ソフトウェアの４つの基本タスク
すべてのソフトウェアは、入力の受付、出力の生成、データの記録、演算の実行という4つの基本的なタスクを実行する。
■メタファー
メタファーは、ソフトウェアテスト技術者にとって強力なガイドになり、テストで達成すべき目的となる。
メタファーは、テスト技術者がアプリケーションを探索するときに従うべき戦略と具体的なゴールを提供する。
■ツーリングテスト
フィーチャは、互いに独立していることはほとんどなく、個別のフィーチャに対するテストは、フィーチャが相互作用したときにのみ顕在化するバグの検出を妨害する可能性がある。
ツーリングメタファーはフィーチャの分解を求めない。テストの意図が要求するアプリケーションの機能やフィーチャの組み合わせは、フィーチャ単体のテストではありえないものとなる。
テスト技術者がフリースタイルの探索だけで行うテストよりも、もっとおもしろくて有意義なシナリオの元で探索を行えるようになる。テスト技術者に目標を与えるので、1つのフィーチャだけをテスト対象とする従来のテスト手法ではもいつかないものとなる。
ツアーは、アプリケーション探索のアプローチの仕方についてテスト技術者の考えを整理することと、 実際のテスト実行を整理することの2つを実現するメカニズム。
■テスト戦略
テスト戦略とは、体系化されたテストのアイデアとフリースタイル探索的テストの適切な組み合わせ。テスト戦略はバグの発見や正確性の検証に非常に有効。
■シナリオベース探索的テスト
市場のユーザーがシナリオに記述されているとおりにしかソフトウェアを使用しないことはありえない。シナリオに変化をもたらすことが、シナリオベース探索的テストの目的。最終的には、追加したステップから元のシナリオに戻る。シナリオの根本的な目的を変更するのではなく、シナリオを強化することが目的。
■シナリオオペレーターとツアーの違い
オペレーターよりツアーのほうが寄り道をする。シナリオオペレーターはシナリオの小さな変更をいくつも行ったり、実施するステップの選択に焦点を当てる。一方でツアーは、より長く、より幅広な派生シナリオを作成する。
■テストチームが開発者と直接連絡がとれない場合のテストの進め方
テストチームが開発者と直接連絡がとれない場合、 壁を通して開発者とやり取りすることになる。
最初は広い範囲をテストする、あるいはテスト対象の概要をテストするツアーから始める。詳細な調査の機会がどこにあるのかをはっきりさせ、具体的なツアー計画を立てるのに役立つ。
最初の探索から次に行う本格的な探索への、フィードバックループが非常に重要となる。テストの早い段階でテストの規律を確立することと、後のテストで戻る場所をはっきりさせる。次に、特に気になるポイントやトラブルのホットスポットにテスト対象を絞り込む。
■テストの意義と欠陥
ソフトウェア産業がイノベーションと信頼性のバランスを取るために頼っているものがテスト。ソフトウェア開発の複雑な性質と、コードを書く際のヒューマンエラーが組み合わさると、エラーの発生はほぼ確実となる。しかし、エラーを管理するとともにエラーの発生を最小限に抑えるプロセスであるテストには、無目的性、反復性、一時性、単調性、無記憶性という重大な欠点がある。
