|
「ソフトウェアテスト 293の鉄則」
Lessons Learned in Software Testing(2002)
Kaner,Bach,Pettichord
日経BP社(2003)
評価：★★★★
私は、ソフトウェアの開発者としての立場から、効果的にデバッグできるHOWTO本のようなものを期待して本書を読みました。
内容はまったく違いました。本書はテスト技術者によるテスト技術者のための本です。
本書でテストに対してのイメージが変りました。
今までは、最初に作るテスト項目と手順に従って行う、機械的な作業だという認識だったのですが、テストとはバグを検出することを目的とした創造的な活動であり、あるテスト結果によって、次に何をするかは、テスターの創造力に任されます。
具体的なデバッグのノウハウはほとんどありませんが、筆者たちが長い経験で得た293の経験則です。
ちなみに「鉄則」というのはLessonの訳だと思うのですが、意味が違うのではないでしょうか？
内容は非常に多岐にわたり、テスト技法、バグの報告などから自動化、ドキュメント、SWEBOK批判、キャリアの積み方、転職の仕方まで幅広いです。
対象はある程度大きな組織でテスト部門が独立しているところのテスターあるいはテスト責任者といったところでしょうか？
しかし、SOHOの私が読んでも損はなかったと感じています。読む人の立場によって、また別の発見があると思います。
最初に抽象的な説明がありますが、それにめげずに、５０ページは我慢して読むことをお勧めします。
共感した部分は
「著者たちは”ベストプラクティス”というものを信頼しない。理由は、最適な手法は状況に応じて異なると信じているからだ。ベストプラクティスの名を冠して売り出されている多くのものが、本来ふさわしくないところに無批判で適用されている、その状況を著者たちは憂いているくらいだ。」
「鉄則００５ 重大なバグを素早く見つけよう」
「鉄則０２１ 技術的、創造的、批判的、実践的な思考が優れたテストのカギ」
「鉄則０４０ 騙されやすいと自覚することが騙されない秘訣」
「鉄則１０８ 手動テストと自動テストを同格に扱うな」
「鉄則１４５ IEEE ８２９ 標準規格も使い方次第」
「鉄則１８５ 『十分なテスト』とは『正しい状況判断を下すのに十分な情報を得られること』である」
「テスト作業は、計画どおりに実行していく作業というよりも、むしろアイデアを生み出す活動である。」
「鉄則１９９ バグ総数によるプロジェクト進捗測定はするな」
「鉄則２０１ 進捗報告にバランススコアカードを適用せよ」
「鉄則２８０ テストケースの項目数からは何も分からない」
「鉄則２８６ 『どうすればより良いテストができるか』を常に問い続けよ」
「異なるタイプの欠陥は異なるタイプのテストによって見つかる。テストは挑戦的であるべきであり、できる限りプログラムが安定するように、あらゆるリスクに着目して行うべきである。」
「いつまでバグを買わされるのか」
Software Conspiracy(2000)
マーク・ミナシ
ダイヤモンド社(2000)
評価：★★★☆
バグを多数かかえていることを承知で出荷されるパッケージソフト、「統一コンピュータ情報取引法(UCITA)」による業界よりの法案。こうしたことが北米のパッケージソフト産業の衰退を招くであろう。それはあたかもかつて、日本やヨーロッパの車に対して米国車が品質向上を迫られたように、ドイツ(SAP)やインドのソフトウエアによって（残念ながら日本ではない）、品質に焦点が当てられるようになるかもしれない。ミナシは、バグとはにか、バグのないソフトは作れるのかを分かりやすく説明した後、消費者として、この問題をどのように、良い方向に持っていけるのかを具体的に示す。第三章からCMMとその反論に対するミナシの見解はわかりやすく説得力がある。
"AFTER THE GOLD RUSH"
Steve McConnell
Microsoft Press(1999)
評価：★★★★
McConnellの4冊目の著作。エッセイ集である。副題は"Creating a True Profession of Software
Engineering"。ほかの分野のプロフェッショナルと同様に、ソフトウエアエンジニアにも免許を与えて、よい仕事をすることをコミットさせ、CMMに基づいた地道な活動で後で、よいソフトウエアを作りましょう。ほかの分野と比較して考察することでいろいろな発見があります。ちなみに後でわかったのですが、このタイトルって、Niel
Youngのアルバムと同じですね。同世代ということでしょうか・・・。
「プログラミングの壺 Ⅱ人間編」
P.J.Plauger
共立出版(1996)
評価：★★★
「プログラム書法」「ソフトウエア作法」は一昔前のプログラマの必読書だった。その共著者の1人であるプローガーのエッセイ集である。3冊出ているが、これは2冊目。ソフトウエアを職業としていく上での人間に関する考察である。突然この本を取り上げることにした理由は簡単で、McConnellが「ソフトウエアプロジェクト
サバイバルガイド」の参考文献に挙げているということを再発見したからであった。もともとは雑誌に連載されたものなので、話題は多様である。読んでいて、古き良き時代を回想してしまった。どちらかというと企業でソフトウエアを作っている人たちよりも、独立してソフトウエア開発をしている人たち向けのアドバイスが多い。プロジェクト管理についての節もあるのだが、冗談を言っているのかどうか、私には賛成できないのでここには載せない。プローガーのような、論理的で、強靭で、シンプルなアルゴリズムを作り出していた人たちは、どこへ行ってしまったのだろうか。
「ソフトウエア開発の定量化手法 第2版」
Applied Software Measurement Second Edition(1996)
Capers Jones
共立出版(1998)
評価：★★★☆
重い、厚い、高いの3拍子揃ったCapers Jonesの本。（おまけにしおりがない）
いろいろな読み方があるが、我々に興味があるのは、多くのプロジェクトから収集した北米の標準データである。
「ソフトウエア開発の最新技術」
日経ＢＰ社(1998)
評価：★★★
日経コンピュータに９７年から９８年にわたって掲載された２８編の主に海外の論文を集めたもの。カテゴリーは「ＷＷＷ技術」6編、「オブジェクト指向」4編、「新手法」3編、「測定／評価手法」7編、「プロセス改善手法」3編、「プロジェクト管理手法」5編である。貴重だと思われたのは、「ソフト開発プロセスの導入効果と実践方法」(米)（CMMに基づく改善活動による、モトローラの貴重なノウハウ。）と「ソフト開発のリスクを管理する実践手法」(米)（SEIの非常に貴重なノウハウ。我々のプロジェクトにすぐにでも導入するべきである。全員に読んでもらいたい。実際のリスク管理で何が問題となるか、どいうメリットがあるか等を６年にわたる実践活動からまとめた説得力ある論文。）である。
「殺人バグを追え」
Ivars Peterson(1995,1996)
日経ＢＰ社(1997)
評価：★★★
医療機器、航空機、原子炉等に使われるソフトウエアの、人命に関わるバグや莫大な損失の原因となるバグの実例と、それを回避しようとする様々な手法が紹介される。ソフトウエア工学の概観にもなっている。
|