ソフトウェアテスト293の鉄則

著者 : Cem Kaner James Bach Bret Pettichord テスト技術者交流会

• 日経BP (2003年4月22日発売)

作品紹介・あらすじ

世界中のソフトウェア技術者の共感を呼んでいる、開発現場から生まれた切れ味鋭い金言集。

感想・レビュー・書評

[Mishikaさんの感想 · 2009年2月7日]

ソフトウェアテストに関する現場でテストに臨んだ歴戦のエンジニアの金言をまとめたもの。
実際にテストをしている人なら、あるあると頷くこともはっとすることも、思わず議論したくなることもあるような、常日頃相対している状況や疑問、苦労に対するポイントをついた言葉が並んでいる。
理論的な手法論のように、明日テストを実践するための直接的な助けとなるものではないが、本を開けばポイントを押さえた言葉に新たな発見がある。
時々テストに疲れた時に気分転換に眺めるもよし、先人の知恵にすがるもよし、どこかで自分と同じように戦っている同士の姿に心震わせるもよし、ライバルに炎を燃やすもよし。

[misahotaさんの感想 · 2023年7月27日]

昨今テストは、自動化されてるので何とも……であるが。
基本的なことは学べそう

[trentakunさんの感想 · 2019年5月4日]

本屋でパラパラ読み、、、

「お！」この情報は？！

→ 「トーストマスターズ」
プレゼンテーションの会？

[ichiro.marinersさんの感想 · 2018年10月23日]

２９３もの提言があるため、100％同意はできないものの、原理・原則はフルアグリー。すばらしい本といえよう。テストを生業とするものや、そのマネージャは必須読本。ソフト開発者も読むべきだろう。

[sugiymさんの感想 · 2016年11月14日]

記載されている内容は納得の内容が多いが、カテゴライズされておらず、内容が飛びがちで若干理解しずらかった。

もう少しテスト設計に慣れてから読み直したらまた印象が変わるかもしれないので、再トライ予定。

[goodseasonさんの感想 · 2016年3月6日]

テストに関わる技術や論理を説明する参考書とは一線を画し、まさに現場での経験則をこれでもかと述べた一冊。
実際にテスト業務(特にマネジメントやリーダー業務)をこなした方ならかなり参考になる。
逆にまだやったことない方は想像できないとこも多そう。
分量は多いが各章がフェーズごとに独立して完結しているので、各フェーズの業務実施中にポイントを読み返していきたい。

[天野遠景さんの感想 · 2013年9月28日]

テスターがここまで考えていれば、相当品質の良いシステムが出来上がるだろう。実際には業務コーダーが兼任でレビュアーもマトモなテストプランのなんたるかを知らない、上層部からはテスト工数圧縮を求められるなど、なんとも理想とは異なることよ。

[kiyoharu-gtさんの感想 · 2012年9月23日]

☆$$つまらなく、挫折したが再読の価値はあると思う。

[akiyama924さんの感想 · 2012年4月30日]

恐ろしいほど、実践的な本です。ノウハウを惜しみなく公開しています。
もし、まだ読んでいないなら、次のリンクをクリックして目次だけでも良いから読んで欲しいと思います。
特に、「テストの自動化」をしようという人は、絶対に「第5章 テストの自動化」を読んでから取り掛かることをお勧めします。

おもしろくて、一気に読めてしまう本ではありますが、私は何度も読み返し、その度に新しい発見をしています。

[silver-fishさんの感想 · 2012年3月4日]

テストのテンプレートやドキュメントにベストプラクティスは存在しない。幻想だ。テストを行うプログラムは誰のために設計され、何をするための処理で、どのような状況の時に利用されるのか。それらの無数の条件により常に「どのようなテストをするべきなのか」は変わっていく。私見となるが、「テスト設計」と「再現性手順の記録書」は重要であると考える。テスト設計では、テスト担当者がなぜそのテストを設計し実行したのか経緯を記載し、テスト中に新たに別のテストを行う事になった記録を継ぎ足していく。そうすることで、数年後や10年後に仕様変更やバージョンアップに伴うテストを行う際に、非常に短い労力で確実にポイントを抑えたテストを行うことができる。
　プログラムの改修がごく一部であるとしても、改修箇所だけのテストで済まず、過去のテストパターンを実行し他に影響がないか確認する必要がある。ドキュメントとしてほんとうに必要なのは、何をすればいいのか、未来のテスターに簡潔に伝え、プログラム改修時の契約の範囲を明確にし、ソフト会社は責任の明確化により的確で確実なサポートを提供でき、顧客企業は責任範囲が明確であるがためにソフト改修費用が大きく圧縮され、財政的に優しくなるメリットがある。
　他のソフト会社が作ったプログラムを別のソフト会社が保守する時に、その線引きが明確でないと、ソフト会社はみな改修・保守したがらず、とても高額な費用を提示し、顧客企業は高い費用を払うか、自前で保守する必要が出てくる、誰も特にならない状態となってしまう。
　テストの記録は大切だよ。