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

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

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

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

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

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


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

テスト技法に関する古典。テストにかかわるすべての人に薦めたい。理論面に偏ることなく、心理学的、経済学的な考察も貴重である。数学の証明のように、論理を追うのに少々疲れるところもあるが、結論だけにでも目を通す価値は十分ある。

参考になった部分を挙げると、

・テストとはプログラムが正しく動くことを示すことではなく、エラーを見つけるつもりでプログラムを実行する過程である。
・テストは破壊的な過程であり、建設的な考えを持った一般的な人間には難しい作業である。
・テストの原則
○結果が自分に都合のよいように見えると言う現象があるので、テスト結果をきちんと定義しておく。
○プログラマは自分の作ったプログラムをテストしてはならない。プログラミングは建設的な過程であり、一夜明けて破壊的なテストをすることは不可能である。
○テスト結果を完全に検査する
○テスト・ケースは、正しい予想できる入力条件だけでなく、誤った予想しない場合も考えて書く。
○プログラムが意図されたように動くかどうかと同時に、意図されなかった動きをするかどうかをしらべる。
○テスト・ケースも使い捨てにしてはならない。
○エラーは見つからないだろうという仮定のもとにテストの計画を立てない。
○プログラムのある部分でエラーが存在する確率は、その部分ですでに見つかったエラーの数に比例する。
・レビュー、ウォークスルーは、ターゲットを使わないテストである。
・テストケースの設計では、どの方法でも、それ単独では不十分であり、さらにほかの方法と組み合わせても完全とは保証されない。
・モジュールテストでは例えば論理網羅（ホワイトボックス・テスト）を基本として、ブラックボックス・テストの集合で補足し、次に限界条件をカバーするテストケースを追加する。
・モジュール同士の結合を、トップダウンで行う方法と、ボトムアップで行う方法のメリット、デメリットを検討し、ボトムアップが有利な点が多いと結論付けている。
・エラー位置発見の原則
○考えよ。
○いきづまったときは、明日までのばそう。
○いきづまったときは、その問題を他人に説明しよう。
○デバッグ道具は２番目の手段としてつかおう。
○ 実験を避けよう。実験は最後の手段である。

等である。