『ソフトウェアテスト技法』を読んだ。
「テスト項目を無限個生成するのは難しくない」とある。値の組み合わせであれパスであれ、全網羅なんてやろうとしたら、あっと言う間に組み合わせ爆発が起きる。「『フカシギの数え方』 おねえさんといっしょ! みんなで数えてみよう!」を思い出す(パステストに近いイメージ)。
というわけで、テスト項目を減らさないといけない。そのために、プログラムを単純化しなければならない。いわゆるウォーターフォール開発だと、これができない。テストする頃にはプログラムは出来ていることになっていて、そんなにガシガシ変更するようなものではないと認識されている。認識を変えるの難しいから、どうしたもんだか。
こういう原理・原則の話だけじゃなく、各種テスト技法の詳細についても解説してくれている(むしろそちらがメイン)。コンポーネントテストはユニットテストの延長で、統合テストはまた別のタイプだという視点を、もう少し消化したい。〈殺虫剤のパラドックス〉と関連していると思うのだけれど、まだ噛み砕けていない。これも認識の問題。なかなか腑に落ちないのは、頭が固くなっているからだろうなぁ。
「テスト項目を無限個生成するのは難しくない」とある。値の組み合わせであれパスであれ、全網羅なんてやろうとしたら、あっと言う間に組み合わせ爆発が起きる。「『フカシギの数え方』 おねえさんといっしょ! みんなで数えてみよう!」を思い出す(パステストに近いイメージ)。
というわけで、テスト項目を減らさないといけない。そのために、プログラムを単純化しなければならない。いわゆるウォーターフォール開発だと、これができない。テストする頃にはプログラムは出来ていることになっていて、そんなにガシガシ変更するようなものではないと認識されている。認識を変えるの難しいから、どうしたもんだか。
こういう原理・原則の話だけじゃなく、各種テスト技法の詳細についても解説してくれている(むしろそちらがメイン)。コンポーネントテストはユニットテストの延長で、統合テストはまた別のタイプだという視点を、もう少し消化したい。〈殺虫剤のパラドックス〉と関連していると思うのだけれど、まだ噛み砕けていない。これも認識の問題。なかなか腑に落ちないのは、頭が固くなっているからだろうなぁ。