はじめて学ぶソフトウェアのテスト技法

知識ゼロから学ぶソフトウェアテスト 【改訂版】を読んですぐに、もうちょっと王道な感じの本も読んでおこうと思って読み始めた。

Kindle 版で読み始めてだいぶ経ってから、会社の本棚にこの本が何冊も置いてあることを知った。二年ちょっと前に会社でソフトウェアテストの勉強会（読書会）というのが開催されていた時期があり、そのときのお題がこの本だった。当時はこういうトピックへの関心が薄かったので参加しておらず、買うときに気づかなかった。

丁寧に書いてあってわかりやすかった。テスト手法の説明が具体的なのが良い。理論的な部分と実践的な部分のバランスも良い。 IEEE とか ISO とかの話は自分が求めるものと少しずれていたので適当に流し読みするにとどめた。演習問題はちゃんと取り組んだほうが良いだろうなと思ったものの、プロのテスターになりたいわけではないので現時点ではそのスキルを磨く必要はないと考え、これもスキップした。直交表など、概念そのものを知らなかったものもあり、それを今すぐ実践で役立てられているわけではないものの、読んで良かったと思う。

はじめて学ぶソフトウェアのテスト技法

以下ハイライト。

• 一番本質的な部分は、「実際どうなっているか」と「本来はどうあるべきか」を比較するプロセスだということでしょう
• テストを実施する人たちは、無意識のうちに不合格にならないテストケースを選択する可能性があります
• この答えを理解するためには、オブジェクト指向の世界で言う契約による設計の考え方を理解する必要があります
• 契約によるテストは、上記の「契約による設計」の考え方にもとづいています。このアプローチでは、事前条件が満足された状況でのテストケースしか作成しましません
• 推測はできますが、「要件の推測」は、許容してよい行為ではありません
• しかし、テストの観点からはとても危険です。テーブルが誤って整理縮小されることは常にありえます。その場合、誤ったコードが書かれることになります。テストケースの設計には、整理縮小されていない状態のテーブルを常に利用すべきなのです
• 無作為な選択はサブセットを選ぶためのとても優れたアプローチになりうるが、やってみると本当に無作為に選ぶのは簡単でないことがわかる
• 直交表は、任意の個数のパラメータに合致するように作成することはできません
• あるテストで必要とされるよりも多くの列を持つ直交表を選択したときは、単純にその列を削除します。それでも配列は直交性を維持しています
• 不必要なセルを含む行を削除したくなりますが、削除してはいけません。直交性が失われてしまいま
• もし行を削除すると、それに対応するテストケースが省略されてしまいます。削除するのではなく、余分なセルを単純にどれかの有効値に変換してください
• よくある誤りは、１つの状態遷移図に複数の異なるエンティティを混在させることです。
• 状態遷移図ですべての遷移をテストするテストケースが、通常はカバレッジのレベルとして推奨できる。
• 状態遷移図は、システムが状態を持たないとき、あるいはシステムの外部からのリアルタイムのイベントに応答する必要がないときには、適用できません。
• テスト担当者がこれらの問題をシミュレートできる支援ツール Holodeckが開発されています。
• 一般的に、ホワイトボックステストは開発者が行う単体テストと同一視されています。必ずしも間違ってはいませんが、それはホワイトボックステストの１つの側面に過ぎません。
• ホワイトボックステストは、単なるコードのテストというよりも、パスのテストです。
• ジェーンはこんがりトースト娘だったけど、軽いバター風味のトーストなんかじゃなく、それどころかトースターの底で真っ黒こげの炭になって、こげたところをナイフでどんなに削ったってまだ下には炭のトーストが残っているようなありさまで、真冬の飢え死にしそうな鳥だって見向きもしないから、もうゴミ箱に捨てるしかないようなしろものだった。
• IEEE標準規格829-1988の“〝IEEE Standard for Software Test Documentation.”〟ほど、スクリプトテストを的確に要約したドキュメントはありません。
• ２．スクリプトテストはその定義上、柔軟性に欠けている。事前に作った筋書きに従う必要がある。テストの途中で何か興味深い現象を見つけた場合も、それをテスト不具合レポートには書くが、深く追跡することはしない。なぜならば、スクリプトにそうしろとは書いていないからで、多くの重要な欠陥がこのアプローチによって見逃される。
• ３．スクリプトテストは、しばしばテストのスキルを低下させる。
• 次に行うテストがその前のテストの結果に何かしら依存するのであれば、ある程度の探索的テストを行っていると言える。
• 「我々は、計画を学習プロセスとしてとらえるべきである。すなわち、状況の理解を改善する心理的な準備行動なのである」
• James Whittakerの著書“〝How to Break Software”〟は、テスト担当者にとって大変参考になります。探索的テストの提唱者は「探索」という行為を推奨していますが、Whittakerのこの本は「どこを探索すればよいか」を教えてくれるのです
• 忘れてならないのは、テスト担当者としての私たちの役目は、製品を出荷するリスクについて経営陣に情報を与えることだという点です