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

私は、ソフトウェアの開発者としての立場から、効果的にデバッグできるHOWTO本のようなものを期待して本書を読みました。
内容はまったく違いました。本書はテスト技術者によるテスト技術者のための本です。

本書でテストに対してのイメージが変りました。
今までは、最初に作るテスト項目と手順に従って行う、機械的な作業だという認識だったのですが、テストとはバグを検出することを目的とした創造的な活動であり、あるテスト結果によって、次に何をするかは、テスターの創造力に任されます。

具体的なデバッグのノウハウはほとんどありませんが、筆者たちが長い経験で得た293の経験則です。
ちなみに「鉄則」というのはLessonの訳だと思うのですが、意味が違うのではないでしょうか？

内容は非常に多岐にわたり、テスト技法、バグの報告などから自動化、ドキュメント、SWEBOK批判、キャリアの積み方、転職の仕方まで幅広いです。

対象はある程度大きな組織でテスト部門が独立しているところのテスターあるいはテスト責任者といったところでしょうか？
しかし、SOHOの私が読んでも損はなかったと感じています。読む人の立場によって、また別の発見があると思います。
最初に抽象的な説明がありますが、それにめげずに、５０ページは我慢して読むことをお勧めします。


共感した部分は
「著者たちは”ベストプラクティス”というものを信頼しない。理由は、最適な手法は状況に応じて異なると信じているからだ。ベストプラクティスの名を冠して売り出されている多くのものが、本来ふさわしくないところに無批判で適用されている、その状況を著者たちは憂いているくらいだ。」
「鉄則００５　重大なバグを素早く見つけよう」
「鉄則０２１　技術的、創造的、批判的、実践的な思考が優れたテストのカギ」
「鉄則０４０　騙されやすいと自覚することが騙されない秘訣」
「鉄則１０８　手動テストと自動テストを同格に扱うな」
「鉄則１４５　IEEE ８２９ 標準規格も使い方次第」
「鉄則１８５　『十分なテスト』とは『正しい状況判断を下すのに十分な情報を得られること』である」
「テスト作業は、計画どおりに実行していく作業というよりも、むしろアイデアを生み出す活動である。」
「鉄則１９９　バグ総数によるプロジェクト進捗測定はするな」
「鉄則２０１　進捗報告にバランススコアカードを適用せよ」
「鉄則２８０　テストケースの項目数からは何も分からない」
「鉄則２８６　『どうすればより良いテストができるか』を常に問い続けよ」
「異なるタイプの欠陥は異なるタイプのテストによって見つかる。テストは挑戦的であるべきであり、できる限りプログラムが安定するように、あらゆるリスクに着目して行うべきである。」