えー、全部テストするんですか？ いまさら聞けないソフトウェア・テストのやり方

山村吉信(著者)

• 販売会社／発売会社: 三元社/
• 発売年月日: 1999/05/25
• JAN: 9784883030569

商品レビュー

2012/04/30

保守テスト（いわゆるちょい変えの時にする回帰テスト）をどこまでやればよいのかについて書かれています。

第1章では、ソフトウェア開発をめぐる諸問題と解決策とされている方法の持つ問題点が書かれています。たとえば、形式的手法については、

　形式的手法の難しいところは「形式的手法に対して、作る前には何を作るのかを指定することは難しい」という単純な事実から来ているのである。

と説明していますし、ISO9000やCMMに対しては、

　実施するには技術を蓄積できる開発グループが必要である。ところで、要員が短期で移り変わる外注化の中では、そんな蓄積など夢のまた夢である。かくして普通の現場に工程管理を持ち込むのは至難の技となる。

と書いてあります。 どちらも、鋭く問題点の本質を突いていると思います。

そして、そのような現状に対して筆者が提案する解決策は、
① テストの網羅性（C0,C1,C2）を計測しよう（テストの努力義務を明らかにしよう）
② サンプリングテストの結果から統計的にバグ数の区間推定を行ったり、信頼度成長曲線により残バグ数＝リスクを認識しどこまでテストしたらよいかについて指針を与えよう
③ 文書管理をきちんとしよう
の3点であり、基本的な考え方としては自分と近いものを感じました。

1番目の、テストの網羅性については、「C言語のコメント（/*　～　*/）を取り去る76行の（コンパイルして確認できる）C言語プログラムと、その状態遷移図」を例として、具体的にC0,C1,C2について説明しているところがとても良い(*)と思いました。ミューテーションテストとエラーシーディングについては、そんなに効果があるとは思えないのですが、まぁ、技術の紹介と言う意味で価値はあります。

※ C0をアド・ホック・テスティングと呼んだり、C2の定義がちょっと疑問だったりしますが……。

2番目のエラーの区間推定と信頼度成長曲線については、私は探針テストの勉強の中で理解していたのでよい復習になりました（というか先に読んでたらもっと楽だったなと思いました）が、現場の人がこの本の説明を読んで理解して使えるかというと、そこまで丁寧には書かれていないので残念です。また、「どのような場合にエラーの区間推定と信頼度成長曲線」を使用することができるのかといった統計処理を行ううえでの「前提」についての説明が不足しているところが問題です。そこのところは、くどいほど説明すべきと思います。

3番目の文書管理については、IEEE 829にそったものです。ただし、うわべの紹介にとどまっているのが残念です。どうして、そのような記録・管理が必要なのかについて突っ込んで書いて欲しかったところです。

ということで、厳しいコメントもしましたが、全体的にいうと私はこの本好きです。この本をみんなが読んで、いいところ、疑問なところについてディスカッションするネタとして使えるのではないかと思います。

2011/08/20

この本をタイトルを見たときに、全部試験（テスト）しないで済まそうという人がいることに驚いた。

16ビットで演算するために試験できないのであれば８ビットにすればいい。全部試験するためには、全部試験できるための設計が必要である。
設計の仕方を考えずに試験をはらそうとするのはなんだろう。
証明してもよい。

統計的な手法をとっている装いがある。
「エラー発見の累積曲線が寝てきて、平均故障時間が十分長いと見込めるときはテスト終了とする。」
とあるが、エラー発見の累積曲線は、平均故障時間とは必ずしも関係がない。

突然、大量のエラーか、致命的なエラーを発見することはしばしばある。
そういう経験値について触れていないのは残念だ。

顧客を言いくるめる方法を考えるにはよい本だと思う。