19冊目読んだ

ソフトウェア・テストの技法

購読理由

ソフトウェアテストの "何を（what）、どうやって（how）" は、OJTで身についたつもり。一方で、それは各論でしかないのではという懸念がある。どういうことかというと、学生時代に居酒屋でバイトをしていたときの感覚と似ているかもしれない。
当時、洗い場→焼き場→揚場→刺し場と見様見真似でなんでもやった。最初は「バイトに作らせたものを出すのか！」と驚いたけど、ルーティン化されているから自分（バイト）がやっても社員（プロ）と大差ない。だけど、自分（バイト）には基礎がない。"さしすせそ" が言えないから、選択肢も少なく、応用力に乏しい。
上記は極端な例かもしれないが、ゼロから作る（創る）のは大変だと思う。だから何かを参考にする。同じ道具を二度発明しないように歴史を学ぶ。その助けになるのなら…と思って手に取った。

感想

初版は1980年と古いけど、これまで当たり前にしてきたことが、当たり前に書かれていて安心した。興味を引かれたのは以下です。

この節では、2つのやり方、増加テストと非増加テストについて述べる。(snip)
各モジュールを別々にテストしてから、そのモジュールを結合してプログラムを形成するのか、または、テストすべき次のモジュールを、すでにテストしたモジュールのセットと結合してからテストすべきなのか、ということである。(snip)
コンピュータ業界での最近の傾向（ハードウェアのコストが減少し、労働コストとソフトウェア・エラーの影響が増大している）と、エラーは早く発見すればするほど、それを修正するコストは少なくてすむという事実を考えると、(snip)増加テストのほうがすぐれているという結論がみちびける。

第5章 モジュールテスト

最近いろいろなプロジェクトで疎結合というキーワードを耳にする。それに対して私は、「状態遷移を再開するからには、ある時点から（プロセスが変わる｜時間的な間隔が空く）としても、遷移元の状態において結合しているといえるのでは？」と考える。非増加テストを否定しているわけではないことは理解してる。でも、その考えを前提にすると、上記引用の「モジュール」という言葉を「プログラム」、「サブシステム」や「システム」にも置き換え可能というジレンマに陥る。（つまり、「そんな厳密にやってたら、本来、並行できることができなくなり、リソースが有効活用できないじゃないか！」ということ。）

ここでの議論は、徹底的入力テストは不可能であることをしめすことである。これからつぎの2つのことが言える。(1) プログラムが、まったくエラーをもたないと保障するようなテストはできない。、(2) プログラム・テストの基本的な考えかたには、経済学的な見かたが必要である。つまり、徹底的なテストは、不可能で問題外であるから、その投資にたいして最大の効用をもたらすことを目的とすべきである（つまり、かぎられたテスト・ケースでみつけることのできるエラーの数を最大にすべきである）。

第2章 プログラム・テストの心理学と経済学

とあるように、バランスを取る必要があることは理解してる。けれど、その落とし所が…ということが本当に知りたかったことです。なんか書いたらすっきりした気がする。