初版2001年ということだが申し訳けないが、資料が古い。<BR>IBM社のSAAを参考資料にあげているが、英語版のころから知っているし、アーキテクチャとして綺麗であることは認めるが、如何せん古い。社内でももう知っている御仁はいないのではないか？。<P>それはおいておくとして、テストが品質管理であると認識できている技術者は少ない。国内でテスティングエンジニアという職種が開発秘書的な待遇が多いのは、彼等自身のレベルの他にその有用性に気が付かない国内の技術者のレベルに問題がある。本書はそういった実情の上にあるのではないため、テストのABCがかかれてはいるが、開発屋が読んで「そういう手法があるのか」と目から鱗の話しはない。寧ろ、進入社員の頃ならった手法を並べてあるとしかとれないだろう。<P>経験として言わしてもらえば、本書は正しい。愚鈍なくらいに基礎を繰り返すことが品質向上に繋がる、それは事実なのだが、技術として目新しいものや、生産工程の省略に繋がるものはない。もっとも品質を保証する工程に省略できるものなどないのであるが。
正直お勧めしません。特に副題が「テストの”プロ”を目指す人のために」となっていますが、テストとは本来どうあるべきか？ということに関する記述や洞察はあまり深くありません。その代わりといっては何ですが、パッケージ開発に必要なテスト項目の羅列はされていますので、さらっと確認するにはいいかも知れません。何にもテストがわからない人向けの教科書であり、「こうやればテストは”とりあえず”できます」という著作です。テストはどうあるべきか、という点を掘り下げる著作ではないですね。よって応用が利かない。カタログみたいな本です。著作の内容をそのままやろうとするとたぶん時間がぜんぜん足りません。では優先順位等は？という問いには答えてくれません。よって結局役に立たない。いや、マジで。（だって条件網羅に関する記述が一ページにも満たないテストの教科書なんて！ありですか、そんなの？）
ソフトウェア開発において、テスティングという項目は、プログラミングに匹敵するほど重要でスキルの必要とされる仕事です。<BR>そもそもその点が日本のソフトウェア開発の現場のほとんどで根本的に抜け落ちている発想ではないか、と思います。<P>この本は、ただ漫然と製品を触ってバグを見つけるのがテスターなのではなく、極めて実践的にテスターがなにをどうテストしどう評価されるべきなのか、テスターが持つ責任、プログラマーが持つ責任、プログラムマネージャーが持つべき責任を、小難しい話ではなく極めて明確に伝えてくれます。<P>それぞれの担当者がどう働けば、クオリティの高いソフトウェアを作り上げることが出来るのか?<BR>いまどき流行りのソフトウェア開発工程本を読む前に、現場の人間がなにをどう良くしていけばいいのかを理解する意味でも、テスターに限らずソフトウェア開発に携わるすべての人に読んで欲しい良書です。
