リスト：プログラムのテストに利く本 を表示しています。（全 21 件）

ソフトウェアの品質を考える場合、いろいろな問題を一緒に考える必要がある。ただ、昔からある問題で、未だに解決されていないにもかかわらず、情報は古いものが多い。この本は、小さな器にも関わらず、最新の話題に触れながら、この領域の「今」を考える最適な本になっている。実に中身がずっしりと詰まっている感じだ。（レビュー人 / 2005-10-06）

マネジメントを覚えるなら優秀なマネージャにマンツーマンで教わるのが一番効果的でしょう。しかし、なかなか、その優秀なマネージャが存在していません。反面教師として見るのもよいですが、やはり自己流ではなかなか会得までの道のりは厳しいものがあります。
ソフトウェアテストを実際に進める上でも、教科書通りにテストを実施するだけではなかなか成功することはできません。テストプロセスをきちんと組み立て、それを上手に動かすことができて成功するのだろうと思います。
この本では、ケーススタディとして、ひとりのベテランマネージャが登場します。まあ、架空の世界ですし、なかなか敏腕なマネージャですからそのまま自分がやることはできませんが、ひとつひとつの手法の真似をしながら、人を動かす基本を学べるなかなか面白い手法の本です。
テストという作業はストレスが掛かり気味になりますが、ぎすぎすした職場を作らないためにも、お勧めしたい一冊。（ / ）

ソフトウェアテストフェーズというのは、ソフトウェア構築全体の遊びの跡が表現されるフェーズである。従ってそこでの結果はおもちゃ箱ということになる。箱の中に残ったおもちゃを良く分析・グルーピングすることで遊び手（ソフト作り手）が何故不具合を作ってしまったのかが仮説を含めて詳細に報告できる。この本はその助けとなる知恵が各章ごとにプロセスチェックリストとして纏められ、テンプレート、様々な事例が補足してくれている。それがタイトルの「１２の必勝プロセス」として活かしてほしいとの意志表示だろう。不具合を分析する際の教本では「ソフトウェア要求：Karl.Wiegers:上流部分」と「ソフトウェアの欠陥予防：Marc.McDonald 他：中流部分」が役だった。Rex Blackのテストの世界を是非堪能してほしい一冊だ。（川島文 / 2009-03-25）

この本はテスティングに関する論文で一番引用されているものだと思う。White boxテスティングを勉強するには非常に優れた一冊である。ただWhite box的テストのアプローチを説明しているので、PCのGUIのソフトをブラックボックス的アプローチでテストしたいという人には向かない。最低限コードを書ける人でないと理解は難しい本でもある。（高橋寿太郎 / 2001-04-16）

P8「一般にはテストはデバッグの後に行うが」という記述があって驚いた。
自分の知っている開発では、デバッグの後にテストを行っている場合があるためです。
ハードウェアにべたべたなソフトウェアでは、テストをやろうにも、デバッグしていないとテストが通らないので、デバッグして、かろうじてでも動く状態になって始めてテストに係ります。
何のテストをしようとしているのか。テストを支える土台がある上でのテストであれば、テストをして、バグを見つけ、そのバグを取る作業をデバッグと呼ぶのかもしれません。
動かないソフトウェアの場合には、動かすためのバグ取りをした後でないと、テストができないことがあります。
P8「デバッグは未知の初期条件で始めることが多く」とありますが、デバッグは特定の初期条件でしか始められません。未知の初期条件で始めるためには、デバッグが済んだ後のテストの段階で、未知の初期条件でも動くかどうかをテストするのではないでしょうか。
P9「テストの設計と実行については、かなり自動化されているが、デバッグについては、まだ夢の段階である」というのは同感です。
（kaizen / 2008-07-08）

　ホワイトボックステストに関して、バイザー先生の
この本を読まずして、プロの間でまともな会話は成立
しないんじゃないでしょうか？
　ブラックボックステストに関しては、同じくバイザー
先生の手になる「実践的プログラムテスト入門―ソフ
トウェアのブラックボックステスト」がおすすめです。
　この２冊に書かれていることを理解せずして、ソフ
トウェア技術者を名乗ることは、ちょっと勘弁して欲
しいというくらい、基本中の基本の書籍だと思いま
す。（こーたろ / 2005-03-21）

各所に散りばめられた皮肉やくすぐりが、密かに面白い。
苦笑すること度々、訳者にも感謝。（tanabe / 2009-02-27）

この本は私がテスト関係の業務について一番に読んだ本です。
姉妹本の　「実践的プログラムテスト入門―ソフトウェアのブラックボックステスト ボーリス・バイザー著 」といっしょに読まれる事をお勧めします。
私がテスト関係の業務をしたころはこの本しか見つける事ができませんでしたが、今はテスト本はたくさん出版されています。この本は分厚い本で読むのが大変ですが、テスト技術者になるにはこの本は最低でも読んでいただきたいと思います。　ソフトウェアテストのバイブル的な本です。（naka / 2008-05-23）

ソフトウェアのテストについて、難しいとか、どうやれば良いのか、
分からないと言った声を多く聞いている。そういった質問に答えられ
る実践的なテスト手法に関する参考書である。少し実践的すぎるよう
な印象も受けるが、そういった点が利点でもある。ただし、例題に出
されているPCに関する状況は少々時代がかっている気もするが、原書
の出版時期を考えるとやむをえないような気もする。
また、付録についているバグ一覧だけを学んでも、デバッグに関する
有効なノウハウが身につくような気がする。（ / ）

ソフトウェア開発において、テスティングという項目は、プログラミングに匹敵するほど重要でスキルの必要とされる仕事です。
そもそもその点が日本のソフトウェア開発の現場のほとんどで根本的に抜け落ちている発想ではないか、と思います。
この本は、ただ漫然と製品を触ってバグを見つけるのがテスターなのではなく、極めて実践的にテスターがなにをどうテストしどう評価されるべきなのか、テスターが持つ責任、プログラマーが持つ責任、プログラムマネージャーが持つべき責任を、小難しい話ではなく極めて明確に伝えてくれます。
それぞれの担当者がどう働けば、クオリティの高いソフトウェアを作り上げることが出来るのか?
いまどき流行りのソフトウェア開発工程本を読む前に、現場の人間がなにをどう良くしていけばいいのかを理解する意味でも、テスターに限らずソフトウェア開発に携わるすべての人に読んで欲しい良書です。（kaorun / 2002-05-24）

　テストの意義、テスト計画のあり方、テストの項目の立て方など、入門編として実践的に懇切丁寧に解説した大作である。丁寧すぎて、ざっと目を通すのもかなり大変な量だが、基本的なことは一通り書かれている。プリンタの事例が多くて、やや古いという点が気になったが、検査や品質管理の専門家はもちろん、開発者でも座右の書として適宜参照すべき本だと思う。あとは自分のアプリケーションに合わせて考えて、カスタマイズする事が重要だろう。そのあたりのヒントはほとんど書かれていない。
　巻末の「よくあるソフトウェア不具合」の４００種類以上の不具合事例のリストと解説は圧巻で、テスト項目の建て方のヒントだけでなく、開発者のセルフチェックにも大いに役立つ。ただしここでもカスタマイズは重要。
　なお随所に、テスト部門と開発者との確執とか、マネージャーやマーケティング部門との力関係、タイトなスケジュールの中でのテスト部門の対処方法などが登場するのだが、これら具体的で現実的な事例や警句には苦笑すると同時に大きくうなづくところがある。こういうところは普遍的なものだ。（まる・ち / 2004-07-04）

Cem kanerは現在アメリカでもっとも影響力のあるPractical testingの人物であるとともに、すぐれた著者であろう。 　企業でのテスティングを学ぶ際に適宜な参考書を選ぶのは非常に難しく、和書に関しては皆無に近い。例えばバイザのBlack box testingなどは良く書店に置かれているがその本を適用しビジネスアプリケーションのテストを行うのはかなり難しいであろう。そういった場合Dr. Kanerの本はうまく適用できるのではないか。多くはBack boxのテスティング手法において説明してあり、テスティングの特別なバックグラウンドがなくても読み進めることができる。更にこの本はアメリカではテスティングのNo. 1の売り上げ書籍である。（高橋寿太郎 / 2001-04-10）

　長年、ソフトウェア開発に携わっては来たが、ソフトウェアテストの基本について、かなり良く解説してある本である。
　設計側から見れば、テスター・テストチームは煙たい存在だが、（これは主に時間に追われているのに、細かいことを言ってくることに起因する）近年ニュースで問題になるような障害を防ぐためには、設計側が障害をださない意識を持つことが重要である。
　テストチームだけではなく、広くソフトウェア技術者に読んでもらいたい一冊だ。（どらいばーII / 2006-01-07）

内容を見ると非常にわかりやすく、それぞれの鉄則が胸に突き刺さることが多い。それぞれの鉄則１つ１つにつき１冊の本ができるようなネタが多い。
まえがきの段階で、用語（兆候・品質・ブラックボックステストなど）の説明をさらっと終わらせ、実践的なことが書かれている。また、テストの技法・手続きだけでなく、後半には、テストチームのマネジメントやテストプロジェクトのマネジメント、ソフトウェアテストにおけるキャリアまで書かれている。
いままで出版されてきたテスト・試験の本とは異なり、体系的に書かれてはいないが本当に必要な技術・思想などが満ち溢れている。
テストとは、ここまで考えてやることなのか、テスト道を究めたいひとにはぜひ読んでいただきたいし、それ以外にもソフト㡊ウエア開発に携わっている方々にも読んで欲しい。（izuminoa / 2003-05-07）

テストに関するノウハウについて書かれていて、とても貴重な本である。原書は米国でテストの実用書としてよく売れている本であり、「テストとはこうあるべき！」というよりも、実際にテストをする技術者の視点でテストの勘所が書かれており非常に参考になる。特に、著者たちのベストプラクティスやＣＭＭなどに対する見解は、規則重視の品質管理に対するアンチテーゼとなるだろう。テスターだけでなく、多くのソフトウェア開発者、ＳＥ、マネージャに読んで貰いたい。（ / ）

２　常に目的を意識せよ
４　顧客の価値と向き合うこと
５　重大なバグを素早くみつけよう
７　口にださなくても、いろいろ疑問を持とう
８　プログラムの失敗を成功の母とせよ
１０　テスト完了と聞いたら注意すべし
最初の１０項目で６項目共感した。
全体の６割が共感出来る可能性が高いと思うか、最初に確実な事項を書いているので、残りは半分以上が共感できないだろうと予測するかは、性格によるか、統計に馴染んでいるかの違いだろうか。（kaizen / 2008-07-08）

テストの現場は過酷である。プログラムや設計と違い、ロクにマニュアル本もなく、経験則が全ての世界。この本は、そんな現場にこそ導入すべき必携ツールと成る一冊といえよう。
これまでの経験則から導き出されたテスト戦略の構築法、バグ出しや試験管理のための実際の技法、さらにはテスターのキャリアアップ指針まで、まさにテスターの道標となるべき内容が盛り込まれている。手探りで進めているそこのテスターのあなたに今必要なもの、それはこの本だと断言しよう。（Ash@VRS / 2003-04-26）

『基本から学ぶソフトウェアテスト…』に続いて凄い本が現れた。
『基本から～』は、文字通り「テスターってなに?」というところから入る本だったのに対して、『293の鉄則』は一言で言えば実践ノウハウ集。
もし、テストやテスターという言葉に馴染みがなければまずは『基本から～』を先に読まれることをお薦めする。
すでに様々なプロジェクトが進行し、ソフトウェアの品質の低さに辟易しているとしたら、職種を問わず、まずこの本を手に取るべきだ。ざっと目を通すだけで、自分たちの問題点や誤った常識が次から次へと見つかるに違いない。
個々のトピックがまさに鉄則、一つとして譲れない項目ばかり。よくある「100の○○」系の本のような薄っぺらな穴埋め項目がないのはその半端な数からもわかる。
夢のような理論/理屈で読者をケムに巻くのではなく、「現実は甘くない、こう対処せよ」という実例や解決方法がぎゅぎゅっと濃縮されている。
とにかく、ソフトウェアの品質管理や検証/テスト部隊には一冊(どころか人数分備えておくべき必読書なのは間違いない。（kaorun / 2003-04-28）

ハンフリーが早稲田大学で講演した際、CMM,CMMIではなくPSPの講演を希望したという。
そのときの講義録は今でも持っているが、PSP入門も持っている。
きっちりした演習があり、人の訓練には適した内容だと思う。
問題は、開発目標が明確で、やる気にさせるものかどうかが不明確な点かもしれない。
最終製品の目的が明確でないのに、ソフトウェアの目的だけが明確になっていることはあまりないからである。
アメリカでは軍の仕事が沢山あるので、暗黙の前提として軍のためのソフトウェアでもよいかもしれない。日本の現在の平和な文化にはなじまないだろう。
（kaizen / 2008-07-09）

ＰＳＰの元祖であるハンフリーさんの本なので、内容は文句なし。
学生向けなので演習用教材として良くできており、訳もわかりやすい。
最近日本のＩＴ業界では「プロジェクトマネジメント」がはやっているが、ＰＳＰはそれこそ自分の仕事をいかにマネジメントするかという方法論であると思う。
なんとなく「やる気」だけで仕事するんでなく、定量化された目標と計数的な実績管理を行っていくという手法である。
考えてみれば、かつて日本の製造業の現場で、個人個人が集まったグループ活動として品質管理活動を行って実績を上げた事例を思い起こさせる。
プロジェクトマネジメントにもっと目を向けさせるという意味で良い本だ。（ / 2003-09-08）

この本は、プログラマ個人の統計的品質管理にかかわるテーマであるが、何もプログラマだけの話ではない。自分仕事などのスケジューリングのテクニックでもある。そこには、安心して約束をいかに守るか、そして、いかにもっと自分を高められるか論理的に導く方法である。ただし、相当な根気と試行が必要である。（オアシス / 2001-10-19）

ある勉強会で、演習問題をやっていったところ、最後までやった人は一人だけだったという話しを小耳に挟んだことがあります。
日頃、間接部門にいると、プログラムを書いていない人には、自分の能力をまずあげることが何よりも必要だということを痛感してもらえれば、大成功かもしれない。
CMMのようなモデルでは、人の能力が必ずしも上がるとは限らないことと、ソフトウェア開発には人の能力が重要で、CMMは能力のある人が集まってもうまくいかないときの課題を解決する方法である。（kaizen / 2008-05-12）

TSP提唱者が、自ら編集した書籍。
CMM,CMMIでは、見落としがちな事象を集めていったら、PSPとTSPにたどり着いたという。
ソフトウェア設計は人が命。
技術力があれば、PSPとTSPで技術を支えることができるだろう。
技術がない場合には、どうするかは、チームの力つまり相互作用で技術力もUpさせればいいのだろう。（kaizen / 2009-07-06）

CMM関連文献で、最初に読んだのが、「ソフトウェアプロセス成熟度の改善」でした。1994年頃です。 当時、CMMを始めとするプロセス評価モデルの標準化として、ISO/IEC15504のTRをISO/IEC JTC1 SC7 WG10で審議していました。本書の翻訳者の藤野先生が、国内の委員会の主査をされていました。
優秀な技術者を集め、当時の技術の最高峰であるAdaを使っても、納期が守れない状況に対して、SEIが、日本などのソフトウェア工場的な仕事の仕方を調べて作成したのが成熟度モデルだといわれています。アメリカのような歴史の浅い国では、日本のような成熟した社会には学ぶものも多かったことが推測できます。
当初はISO/IEC 15504の内容も、経験的な事項で役に立ちそうなことが沢山書かれていました。その後、標準として他の規格との整合性を取ろうとして、形式的な記述が増えてしまったかもしれません。
ちょうど、2008年にJISが発行されました。約１５年かかったことになります。
JISを読む人も、この本も併せて読むとともに、PSP、TSP、PeopleCMMも併せて読むとよいかもしれません。
ps.
1993年にISO 9000のソフトウェアへの適用を検討していました。情報処理学会情報規格調査会の会員企業の方から推薦されて、ISO/IEC15504の標準化に取り組むことになりました。 （kaizen / 2008-04-22）

CMM/CMMIの基礎的な考え方を詳細に解説した内容。
CMMIの教育を受講して、消化不良な方にお勧め。
最近のCMMIの書籍＆教育では、省略されている意図のような部分も理解できる。
CMMI推進者、CMMIに取り組まなければならない実務者必携。（naushika279368 / 2007-07-04）

著者は長らく日立に勤めていらっしゃたようで、日立での品質保証システムを紹介していると想像する。
その品質保証システムは非常に質の高い、確固たるもので学ぶべき点は多い。内容は多少難しくアカデミックな面も多少あるが、既に実践されている内容なので、自分のソフトウェアプロジェクトに導入するにもハードルは決して高くないであろう。
この本で一番特筆すべき点は、日本人による日本の品質保証システムを体系的に書いているところにある。アメリカのソフトウェアの品質保証システム（特にテスティング関連）は、多くの翻訳によって紹介されているが、日本のそれは多くはない。
常に机の横に置いておき、なにか品質問題があった場合に参照するには最適な本と思われる。（高橋寿太郎 / 2004-07-24）

P96のVer.でカバレッジの分析するのは
私は今までしていなかったです。
図3.11の方法はいつのVer.でテストしたか一目で分かるので
いいですね。
私はやったか、やっていないかしか管理していなかったので
数値で重み付けするのはすごく分かりやすいと思いました。
☆これがあると
「今回のテストはどこに重点を置きましたか？」
と会社の上層部から言われたときは、すんなり点数で
答えられます。
今まで私は、テスト時間で言っていました。
この場合、バグがあるところは何回もテストしなければならず
単純にテスト時間が多いとしかいいようがなかったので
ここに時間をかけています。
と主体性のないことになっていました。
テスト計画時に新規機能はそれなりに
他よりもテスト項目を多くしてテストしますが
時間で測ると、回帰テストが多くなる分
バグの多いところの方がテスト時間が多い結果となりました。
この本は外にも全体的にテスト管理の事が書いてある為、各社の品質部には
必須の本であると思います。
すばらしい！（naka / 2004-05-23）

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

著者の経験に基づいた事象が、いろいろ記述されている。
体系的に今後勉強する際の、一つの入り口として使うことができる。
ps.
コラムにCMM,CMMIについて述べているが、能力水準モデルの枠組みとしてISO/IEC15504があること。供給側のみでなく、調達側も評価しないと取引には有効ではないことが十分に述べられていないのは残念だ。（kaizen / 2008-05-04）

タイトルに「実践」とあったので、もっと具体的な試験項目の作成方法などがのっていると思っていたら、内容は「読み物」だった。
付録のテスト計画書、手順書も中途半端。
どうせなら、本文のだらだらした説明を削って、例えばあるサンプルシステムの完成したテスト計画書、一連の試験手順書（ユニットテストから総合テストまで）を載せてほしかった。
あと、本文中に参考文献が載っているのは良いが、巻末にリストとページ番号をつけて欲しかった。後から探せない。
タイトルにつられ、買う本を間違えてしまった。（ルチアcf / 2005-03-22）

テスト専任者では無い自分にとっては、あまりピンとこない内容のものが多かったです。
この本を読んで、初めてカバレッジ(網羅率)という言葉を知りましたが、それ以外あまり得たものはありませんでした。
限られた製作期間の中で、あまりテストの時間を使えない人。
それでいて尚且つ「これで良いのか？」と思っている人には
別の書籍を読んでも良いかもしれません。
内容は分かり易く書いてあったのですが、もう少しインパクトが欲しかった・・。（ノグチョ / 2005-11-24）

テストに関わるetc etcを綴った本でした。
テスト計画の立案方法・内容、実際のテスト工程の進め方、テストの設計や実施の上でのポイントや注意点等が説明されています。テスト技法や、テストツールの使い方、統計的な管理手法等の話題は、ほとんどありません。
体系的にテストが論じられているのではなく、筆者の経験等から、テストのポイントになることが、論じられている部分が多かったような印象です。その分、全体的に読みやすい本です。読み物みたいでした。
テストを計画する立場あるいは、管理する立場にたつときに、役立つ本であると思います。「さらさらっと読める」ので、テスト計画を立てる前に、ご一読を！という感じの本でした。（lemonerika / 2005-04-17）

テストの基礎知識が身に付いた上で，次に目指すべき方向を教えてくれる良書．
抽象的な説明と具体例のバランスが良い．また，参考文献についての記述も
本文中にあるので，それを元に自分に不足している分野をカバーできる．（amazon_hk / 2004-09-25）

おおまかにテストとはどんなものかがわかった人が次のステップへ行く為に必要な本です。
ブラックボックステストについて書かれています。
色々なテスト技法も書かれているので、大変参考になりました。（ / 2005-02-25）

ソフトウェア試験の理論の構造が理解できた。
１７条憲法は、十戒＋１だそうだ。
その他の戦略という項が、英語の見出しがないのは残念。「その他」は、違う用語の方が分かり易いかもしれない。
７章のドメインテストの項は、ドメインテストとは何かが明確に記載がないまま、７．１概要、７．２用語と進んでいるのには抵抗感があった。
ツールと自動化では、具体的なツール名がでてこなくて、論文名が紹介されているのにも抵抗感があった。
大学の講義用なのかもしれないが、現場でも読みたくなるような情報もあると嬉しいかもしれない。（kaizen / 2008-07-09）

　ブラックボックステストの教科書的存在です。
この本を読まずしてソフトウェアエンジニアを
自称していると、すぐに底がわかってしまいま
す。
　ホワイトボックステストに関しては、同じく
バイザー先生の手になる「ソフトウェアテスト
技法―自動化、品質保証、そしてバグの未然防
止のために」は、この本とあわせて必読書籍で
しょう。
　テストドリブン開発をやるにしても、こういっ
た地味でなおかつ基本的なことが身についてい
るかどうかで、成果に大きな違いがでてきます。（こーたろ / 2005-03-21）

レビューのタイトルに書いたとおりです。人によって、この本のどの部分に共鳴するか違うと思いますが、私の場合はこうです。
『テストはバグの無いことを証明するために行うのではない、バグを検出するために行うものである。』
我々は、プログラムのコーディングが終わった時点でバグがないことが有り得ないことを直視しなければならないです。
良く似たタイトルで「ソフトウェアテスト技法」（ボーリスバイザー著）というのがありますが、量は５倍くらいあると思ってください。全部は簡単には読めません。
それと比べて、こっちの「ソフトウェア・テストの技法」（マイヤーズ著）は１０〜２０時間くらいで読めると思います。それで、現在のソフトウェアテストに続く基本的な考え方が詰まっています。
・ホワイトボックステスト、ブラックボックステストから始まって、
・ウォーターフォールの原型に基づくシステムテストのポイントまでが
３０年近く前のこのマイヤーズの本に既に書かれていることは全くの驚きです。
※ 「トヨタ生産方式」（大野耐一著）を読んだときと同じ驚きです。（yu-ji / 2006-11-02）

テストに関する基本的な考え方（あり方や取り組み方）をわかりやすく教えてくれる本です。
テスト技法の古典に属する本ですが、テストの基本中の基本（時代が変わっても普遍的な考え）
をおさえた価値のある一冊だと思います。（ / ）

まず初めに英語の題名はThe Art of Software Testingという素晴らしい題名なのにでなぜそれがソフトウエアテスト技法に邦訳されてしまうのかが理解に苦しむ。
70年代の書籍である、しかし2000年になった今も書籍の内容の良さは変わらないであろう。ソフトウエアテスティングはこの30年間進歩はしてきたが著者が書いた基本的テクニックを逸脱するものでも否定するものでもない。唯データフローテスティングと状態遷移については書かれていないのでそれについてはバイザーの書籍を購入する必要があるであろう。（高橋寿太郎 / 2003-10-01）

ソフトウェアのテストについて論じる場合、必ず目を通す必要のある良
書。あまたのテスト関連本でこの本が参考文献に載っていないものは皆
無といってよい。
確かに古い本なので、具体例などで違和感があるかもしれない。しか
し、時代によってツールや用語は変われども、テストをする際の着眼
点・基本的な手法はかわらない。この本は、品質、障害、テストについ
ての考え方・概念について簡潔にかつ本質的な点を語ってくれている。
むしろ小手先のテクニックではなく、ソフトウェア品質の本質を真に理
解することが重要なことなのだ。（エパメイノンダス / 2006-01-17）

20年以上前の著作であるので、参照されている開発言語等は当然役には立たないと思われます。が、テストはどうあるべきか、ということを明快に整理している本です。180ページ前後の著作ですが、テストはそもそもどうあるべきか、という意味で非常に勉強になりますし、自らがシステム開発の際に採用しているテストの手法・内容が適切・十分であるかどうか素早く確認するには良い思います。SEのまたはQAの担当者の方であれば一読をお勧めすると同時に、しばし読み返すのも悪くないと思います。他の著作に割と引用されている本の一つでもあります。（御神苗 / 2003-09-14）

プログラミングの世界ではxUnitを使ったテスト駆動プログラミングは既にポピュラーですが、その考え方をプロジェクトのすすめ方にも適用するという内容です。
プロジェクトのサブシステム担当として参加することになり、開始直前にこの本を購入して第1章から第4章までを読みました。お客様とサブシステムの受け入れテスト仕様について合意後に開発作業に着手しました。その結果、開発後のゆり戻しがほとんど無く、スケジュールより1週間短縮で作業が完了しました。
私のように「テスト」についての勉強をほとんどしたことが無い方にお勧めです。逆に、有効なテスト手法を自分なりに確立している方には、有益な情報は少ないのではと思います。（marujunjun / 2005-09-22）

以下の４部からなります。
（１）開発方法論（開発プロセス）
（２）「分析->設計->テスト」などの各プロセスで、何をどのような手法で、どう行っていくか、そこで使える知識、また、Ｗｅｂプロジェクトでの応用例
（３）プロジェクト管理の知識。スケジューリング、見積もり、品質管理など
（４）先進的トピック。新しい方法論（フォーマルメソッドなど）
です。
ボリューム的には、（２）が圧倒的に多かったような気がします。
全体的に広い範囲の話が、網羅的に記述されています。小さな字でびっしり書いてあり、そこそこ詳しく記述されています。体系的に、わかりやすく書いてあります。
実践とあるとおり、アカデミックなものではなく、あくまでも実践で応用できるように書かれている印象の本でした。
なるほど、こんな方法があったのか、と参考になることが、沢山ありました。「オブジェクト指向におけるテスト手法」「Ｗｅｂシステムにおけるテストの注意点」が体系的にまとめられているなど、（個人的）に興味深い点が、沢山ありました。
手元において、仕事に使える印象の本でした。（lemonerika / 2005-04-09）

本書は海外でも多く利用され、世界中のSEに親しまれてきた本である。また標準的な教科書である。本書は、版を重ねるたびに、内容が進化しており、驚くほど用意周到に準備されている良書である。本第６版では、特に現在流行っている、オブジェクト指向やWeb開発の内容が豊富に含まれている。その上、最近多く出版されている、オブジェクト指向や、Web開発の本だけでは学べない、プロセスやマネジメントについても総合的に包括的に記述されえいる。システム開発の入門書として、また知識や経験を頭の中でもまとめるに当たっても役に立つ本である。実践向きの本なので、広くSE、PM、ANの方に読んでいただきたいと思う。（chukanshi / 2005-10-06）

4ヶ月かけて通勤中に少しずつ読んでひととおり読むことができた。
本書の構成は、一般的なプロセスとWebアプリやアジャイルにフォーカスした内容が記載されている。
それぞれの章は、プロセスの概要とポイントが書かれている。PMBOKのそれと同じく、読む人のニーズに沿った仔細な回答が書かれているわけではない。
開発プロセスはどのようなフェーズで構成し、フェーズの中でどのようなワークパッケージを組み込むかのポイントが書かれている。もし深い興味を得た事柄があれば、数多く記載されている参考文献を読むことだ。是非とも、経験を積んでいる最中の中堅SEに読んでいただきたい。もちろん、経験の浅いSEも新しい知識を得るために読んで欲しいし、熟練SEやPMも新しい知識の風を取り入れて欲しい。（ふみさん / 2006-05-07）

システム開発にまつわる様々な分野を網羅し、体系的に説明した書籍です。
業務経験が長くなると自分の勘や経験だけで問題を解決しようとする人が多くなる気がします。
しかし、プロであれば車輪の再発明をするのではなく、十分に実証された既存の技法を活用したいものです。
また、この本は読み物としてだけではなく、リファレンスとしても使用することが出来ます。
あまり自信のない作業分野を担当しなければならない場合や、自分の手法の妥当性を確認したりする場合にも有用です。
第3部は「Webエンジニアリングの適用」がテーマですが、これは社内イントラネットシステムのようなWebシステムではなく、いわゆるインターネットサイトを対象としています。
人によっては有用かもしれませんが、汎用的な知識や技法を提供している他の章に比べると特定の分野に特化しすぎていて若干異質な感じがしました。
原著はすでに第7版が出ているようで、こちらの目次を見るとWebに特化した章はなくなっているようです。目次だけ見るとさらに汎用性が高まった内容が期待できそうなので、こちらもいつか読んでみたいと思います。（伊藤淳一 / 2009-11-02）

エンジニアリングの世界で迷わないための地図として、強くお勧めする。
エンジニアとして仕事をする上で大切なのは、「バランス感覚」。
いくら個別の技術に精通していても、製品品質は上がらない。
この書籍が優れているのは、冒頭から最後まで、一貫して
品質にフォーカスしていることだ。
原則が端的にまとめられているのも非常に参考になる。
本書でエンジニアリングの全体像を確認しながら、
個別技術を学習していけば、確実にステップアップが図れる。（ishtaredge / 2008-05-30）

テスターをやっています。
テストは新人開発者がやるもの、とかよく聞きますけど、本当なんでしょうか？今所属しているテストプロジェクトは未経験者を採用しています。それは仕方ないですが、初日に「OSって何ですか？」と聞かれました。テストマネージャーには「できるだけバグを出さないように」と言われています。要するにテストチームは素人集団で良い、ということになっているのでしょうかね。あまりに落胆したので本書を衝動買いしたところ、期待以上にしっかりとした内容で、それもコンパクトに書かれていて気に入りました。電車の中で読みながら、これが仕事の基本だよなーと平常心を取り戻すことができました。著者の方、ありがとうございます。タイトルの「知識ゼロから～」も気に入っています(いざとなったら「これくらい読め！」と投げつけられる？)。
今度はぜひ上級者(というか、テストの理想を追い求めたい人)向けに書いて欲しいです。よろしくお願いします。（ / ）

　最近ソフトウェアテストの本が結構出てるけど、みんなページ数多いし字も細かいし、なんかソフトウェアテストの入門にいい本はないかなー、と思っていた矢先にいい本を見つけました。
　筆者の方はMicrosoft、SAP、ソニーといったビッグネームでテストを担当してきた歴戦の古参兵だけに、載っている事例も具体的かつ実のある（そしてちょっと苦笑いさせられる）内容です。
　恥ずかしながら、私はソフトウェアに携わる仕事をしていながらも、この本で自分の知識の浅さと狭さに気づかされました。開発工程の何割かを占めるテストについて、正しい知識を身につけることは大切ですね。
　これを読めば明日からの仕事がバリバリ進むという本ではありませんが、ソフトウェアのテストについて知る入り口としては最適だと思います。（ / 2005-03-07）

ソフトウェアの開発手法やテスト手法というのは、どこにも完璧なものは存在しません。
それを踏まえた上で、如何にうまく付き合っていくかを、筆者の豊富な経験に基づいて
書かれた書籍です。内容が正直でとても共感が持てます。
テストの本質が何か、そして何が大切であるかを、平易な内容でわかりやすく語られています。
テスト担当者でなくても、その管理者、そしてプログラマーの方にも是非読んでいただきたいと思う一冊です。（tagachil / 2007-01-19）

バグが発見されると大騒ぎされる会社(ＭＳ，ＳＡＰ，ＳＯＮＹ)
を渡り歩いている著者によるテストの教科書本です。内容としては、基本情報処理の資格取得した人が実務でテスト業務をする際に身に着けるべき内容となっています（少なくとも知識として知っておくと、よい）。
詳細を説明すると（ホワイト・ブラック）*ボックステストの基本手法から始まりシステムテストやソフトウェアテスト運用（費用対効果に優れる手法とは）そして、品質管理まで包括的に含まれてます。１テスターとして感じることと、管理者（著者）が感じることがかいてあります。
そんなテスト体制より、こっちのほうがいいですよとか
ですマーチは御免ですたいというＰＪを見分けるのに役立つかも（当然改善にも）
30代前半までに、著者の書かれた経験をされた方には、
自分の会社のテスト体制に一言言える状態になるかなって感じです。（こると / 2006-01-03）

注)ソフトウェア開発者としての意見です。
この本は、タイトル通り知識ゼロから学ぶに適した本だと思います。
簡潔にわかりやすく、テストの手法などについて学ぶことができます。
テストの本に関しては、読み進めていくのが難しい書籍がありますが
まず始めの一冊として読んでみてはどうでしょうか。（ノグチョ / 2005-11-25）

ソフトウエア開発の現場では、今でもいろんな混乱がある。
■工期短縮のためには工数増が必要であるのも拘わらず、プロジェクト開始後に要件決定の遅れや納期の短縮要求をズルズルと受け入れてしまう。
■トップがその年に決めた目標(たとえば生産性向上５％)を達成するために、他の重要なメトリックスを悪化させてしまう。
この本の中では、ソフトウェア開発の分野では中核となるメトリックスは５つある（規模、工数、工期、品質、生産性）といい、６３００の実績データの分析、メトリックスの導入、注意事項について解説している。
全体を通して痛感するのは、何を測るか、それをどのようにフィードバックするか、こういうことを継続して考えていかないと５つのメトリックスを同時に改善していくことはできないということ。本書の中で引用されている、絶対温度で有名なケルビンの「計測できればコントロールできる」という言葉が強く印象に残ります。日本でも、ソフトウェア開発分野のプロセスエンジニアという職種が定着することが必要とも感じました。（yu-ji / 2006-09-13）

2000年までの6300件のデータをもとに、多くのグラフを用いて説明されており、非常に説得力があります。
概念的には、機能総量＝プロセス生産性×工数×開発時間で表すことができます。この関係からわかるように、工数と開発時間はトレードオフ関係にあり、開発時間を延ばせば工数が減ることになります。
従来の見積もりでは単に人月であり、開発時間を考慮していないため、正確に見積もれないことがわかります。（100人月：100人なら１ヶ月？１人なら100ヶ月？）
どんなに頑張っても（コスト・人を投入しても）これ以上早くは開発できないという最短開発期間が存在するというのも、目から鱗でした。無理ムリのスケジュールでの開発は、破綻することになります。
計測されたデータの分析結果が主になっているので、いざ実際に計測しようとすると、他の書籍などを調べる必要があるかとは思います。
5章と11章だけでも読む価値があるかと思います。（tkcjun / 2005-12-03）

ソフトウェアのプロマネ本の1つです。
ソフトウェアの開発を管理する上で、気を配らなければならないことが書いてあります。作者の長いソフトウェア業界での経験が凝縮されていて、その点は参考になります。
しかし、少し内容がふるいのが気になります。1980年代の前半の話などがよく引用されて出てきます。さすがに20年前の話をされても困ります。
で、トータルすると星３つ。（ユングベリ / 2008-12-21）