ソフトウェアによるテストといっても、
ハードウェアの仕様を確認するためのテスト、
コンパイラなどの設計の道具を確認するためのテスト、
設計の可能性を確認するためのテスト、
設計内容が意図した通りに動くかのテスト、
不具合があったときにデバッグするためのテスト、
製品を出荷するための基準を満たしているかを確認するテスト
購入した製品が利用開始してもいいかどうかの受け入れのためのテスト
いろいろな観点でのテストがある。

本書では、いくつかの視点を説明しているが、すべての視点を網羅している分けではない。

自分がテストを考える上での１例を知るために読むとよい。

抽象的に考えると、何でも当てはまるが、役にたたない。
具体的に考えると、役に立つが、横展開をするためには汎用化が必要だ。
万能の解決策がないのだろう。

誰にとって必要なテストかをいつも考えているとよいのかもしれない。

P96のVer.でカバレッジの分析するのは
私は今までしていなかったです。
図3.11の方法はいつのVer.でテストしたか一目で分かるので
いいですね。

私はやったか、やっていないかしか管理していなかったので
数値で重み付けするのはすごく分かりやすいと思いました。

☆これがあると
「今回のテストはどこに重点を置きましたか？」

と会社の上層部から言われたときは、すんなり点数で
答えられます。

今まで私は、テスト時間で言っていました。
この場合、バグがあるところは何回もテストしなければならず
単純にテスト時間が多いとしかいいようがなかったので
ここに時間をかけています。
と主体性のないことになっていました。
テスト計画時に新規機能はそれなりに

他よりもテスト項目を多くしてテストしますが
時間で測ると、回帰テストが多くなる分
バグの多いところの方がテスト時間が多い結果となりました。

この本は外にも全体的にテスト管理の事が書いてある為、各社の品質部には
必須の本であると思います。
すばらしい！

「テストプロセス管理」と銘打たれているが､実際にはテストマネージメントもしくは､テストの進め方について書かれた本である。
非常に､項目のまとめ方やテスト結果の把握方法など詳細に書かれており､実践に参考になることが多い。