『ソフトウェア・テストの技法 第2版』を久しぶりに読んだ

『ソフトウェア・テストの技法 第2版』 を再度読んでみました。

読み直す、と積読にしてたもの。

入門的なものなので、結構前に読んでいたのですが、改めて軽く読んでみました。ソフトウェアテストであったり、デバッグであったり。プログラムを書く上で、エラーを見つけて治す、というところに対する原理原則をまとめている書籍です。

用語の定義は置いておいて、昨今の開発者テストの文脈で開発者も多少は目を通すのも良いかなと思った内容です。

ソフトウェアテストの心理学

テストとは、エラーをみつけるつもりでプログラムを実装する過程である。

(この書籍における)ソフトウェア・テストの原則

1. テスト・ケースの必須条件は、予測される出力または結果を定義しておくことである
2. プログラマは自分自身のプログラムをテストしてはならない
3. プログラム開発グループは、自分達のプログラムをテストしてはならない
4. それぞれのテストの結果を完全に調査せよ
5. テスト・ケースは、予想できる正しい入力条件ばかりでなく、予想しないあやまった場合も考えて書かなければならない
6. プログラムを調べるのに、それが意図されたように動くかどうかを見ただけでは、なかば成功したにすぎない。残りの半分は、意図されなかった動きをするかどうかを調べることである
7. プログラムが本当に使い捨てのものでないかぎり、そのテスト・ケースも使い捨てにしてはならない
8. エラーはみつかれないだろうという仮定のもとにテストの計画をたててはならない
9. プログラムのある部分でエラーがまだ存在している確率は、既にその部分で見つかったエラーの数に比例する
10. テストとは、非常に創造的であり、知的に挑戦しがいのある仕事である

そういえば、エクスロリームプログラムにおけるテストであったり、インターネットを含んだWebアプリのテストの話が載ってました。2版で追加されたものですね。

前者は、JUnitなどのフレームワークも用いた、自動化されたテスト群をおもに扱っていました。後者は、ネットワーク含むシステム全体を、ネットワーク/DB/Webアプリのモデル層などのように区分して、それらに関わるテストの話を載せていました。

Webアプリのテストの話では、コンテンツ・テストとしてGUIに関する要素が、利用時の品質に大きく関わる、という文書がありました。おもに回帰テストにおけるテストの実行速度の面になるとどうしても優先度下げられたり、人海戦術任せになってるところがありますが、ここら辺は利用時の品質に大きく関わる(利用者が多ければ、尚更)箇所なので、ちゃんと言及されているのは良いことですね。

システム全体の構成の話、目新しさは無かったのですがそこらへんの要素を経験/学んでいない場合は目新しさに映るのですかね？昨今ではそれぞれの箇所で専門性が高まったり、よくあるSeleniumを使ったE2E系の話しだとそれらの多くの要素が(意図的かどうかは置いておて)省略されている場合もあって、システム全体に対する構成に対する想像がされない世界になってきている気がします。

隠蔽された良い面と、開発やテストを行う者としては知らなさがシステムを造る上では悪い面がありますね。