『パーフェクトソフトウェア』

『パーフェクトソフトウェア』を読み返している。
　
前回読んだときは「さらっと」流してしまったようで、全く印象に残っていない(^_^;)。
　
この本は、ノウハウ集やベストプラクティス集のようなものではなく、技術書というよりもエッセーに近いと思う。
そして「あるあるネタ」でもある。
だから、気楽に、気になったところを読めばいい。
実は、内容は「てんこ盛り」で、私はちょっとしんどいかったのだった。
　
各章の最後には、「まとめ」のあとに「よくある間違い」というセクションがある。
「まとめ」のほうは一言すぎちゃって、こっちのほうが本文の内容を理解しやすいまとめになっていると思う。
さーっと流すなら、ここだけ読むのもいい。
　
　
では、本の中から「テストとはなんぞや」についてをピックアップしてみる。

テストは製品に関する情報を収集する業務である。

テストは製品を良くするものではない。
製品を良くするのは、テストで見つかったバグを直す人たちの仕事だ。

テストはせいぜいサンプリングである。

大量のテスト ≠ 十分なテスト

テストが成功したかどうかを確実に知る方法はない。

　
　
「テストに関する主な誤謬」という章もテストのことをよくあらわしていると思う。
引用と、少し私の意訳も含めてで、以下に挙げておく。

非難の誤謬
避難を浴びせれば効率よく問題を解決できると思っている。
実際にはその反対であることが多い。
　
完全なテストの誤謬
「完全に」テストできると思っている。
　
テストが品質を作るという誤謬
品質は開発プロセス全体から生まれるものだ。
プロセスの他の部分がすべて正しく構成され実行されないかぎり、良いテストを行っても品質を良くすることはできない。
　
分解の誤謬
ユニットテストでバグはすべて見つかるから、システムテストは余計だと考えて省略する。
　
合成の誤謬
システムテストでバグはすべて見つかるから、ユニットテストは余計だと考えて省略する。
　
テストなんてどれも同じという誤謬
同じように見えるテストでも、それぞれテスト設計者の意図や目的があるものだ。
実施方法やテスト対象が似ていたり同じだからといって、同じ情報を得ようとしているとはかぎらない。
　
テストなんて誰でもできるという誤謬
あなたと私のテストスキルは異なるということ。
それと、前にやったテストはその後のテストに大きく影響を及ぼすということ。
テストのノウハウを得ることと、テストや製品に関する最新の情報を得ることの両方において。
　
　
この本は副題に「テストにまつわる幻想」と付いており、そういう幻想のひとつひとつを教えてくれるものの、
「こうしたらいいよ」という、てっとり早い答えを用意してくれるわけではない。
あくまで「テストについて」を知るための本なのだ。
やり方を知りたければ、テスト技法について勉強して下さい、ということだ。
　
　
その他、内容は盛りだくさん。
　
メタ情報のことや、情報の使い方のこと。
情報の使い方を身につければ、テストの効率を大幅に高め、コストを抑えることができる、と
　
情報の認知から行動に至るプロセスのこと。
　
製品のテストだけでなく、人のテストやプロジェクトのテストについてもふれている。
　
レビューのこと。
レビューはテストの一種である、と。
　
「インスタントレビュー」という簡易なレビューの実施を奨めている。
　
「最悪を最初に」とは、「最悪のものから手をつけろ」ということなのだが、
「最悪とはいったい何なのか」というような、レビューの目的や観点を共有し、
みなが同じ視点でレビューを行うことは本当に難しい。

SQiP のページに「３分割レビューの提案」というプレゼン資料があって、
これなどもそういったことに対するアプローチのひとつだ。
　
それから、カバレッジのこと。

コードのすべての部分を何らかのテストでふれたことを証明できたからといって、
その部分が完全にテストされたとはいえない。すべての機能を完全にテストしたとはいえない。
テストの関連性と包括性を分析する必要がある。

　
その「テストの関連性と包括性」をどう分析したらいいんだよ～、と涙を流して訴えたいくらいなのだが、
そこんとここそが我々のお仕事ってわけだよね。
　
周りのみんなはどんなふうに考えているのか、一度訊いてみたいな、と思った。