参考文献
『
ソフトウェアテスト HAYST法 入門』（以下、「HAYST入門」と記述）で参考文献としてリストした書籍の紹介（＆雑談）です。
よく、「初心者に向く本はなんですか？」とか、「テストマネージャ向けの本を紹介してください」と言われるのですが、もし、あなたが会社員なら、部門で以下にあげる本や論文を全て揃えてしまう事をおすすめします。20万円でそろいます。
そして、本棚を作って（といっても1mの幅の本棚が2本で十分です）みんなが読める環境を作りましょう。
とっても安い投資で、効果絶大だと思うんだけどなぁ。
第1章～第2章
ソフトウェアの現状と、ソフトウェアテストの概略について記述した章の参考文献です。
品質工学講座（全7巻）の1巻目にあたるこの本は、製品企画・製品設計・生産工程の設計に焦点をあて、設計定数、工程定数の中心値を決めるパラメータ設計と許容差の設計を効率よく行う方法について記述されています。ただし、ソフトウェア技術者が品質工学について初めて読む本としては少々難しいかもしれません。
必要に迫られて実践しながら勉強する時に役に立つ本です。「HAYST入門」の著者の１人である吉澤正孝が編集主査を務めました。
ES―2，NIST（National Institute of Standards and Technology），2002．5．
NISTとは、アメリカ合衆国の国立標準技術研究所です。工業規格の標準化を推進しています。本レポートには、「ソフトウェアのバグによる損失額が600億ドル近く（GDPの0.6％に相当）に達していること、そして、テストの強化によって、1/3以上の損失は減らせる」と記述されていたため非常に衝撃的なものでした。それから５年が経ちましたが状況は変わっていない（むしろ悪化している？）ような気がします。
概略を日本語で読みたい方は、渡辺弘美氏の
レポートが参考になります。
『特定サービス産業実態調査』，2006 年．
「HAYST入門」で、情報サービス産業の売上高を14兆円（2005年度）としている根拠が載っています。売上高の何％をバグに喰われているかは不明ですが、かなりの額になることでしょう。
「HAYST入門」では触れていませんが、日本の情報サービス産業は、子請け、孫請けの世界なので、売上高の総和値については多少割り引いて考える必要があるかもしれません。
（例えば、10億円で受注したシステムを売上高の50%にあたる5億円で下請けに発注した場合、産業全体では15億円の売上げになります。これをさらに孫請けにと繰り返していくと等比数列の和の公式から全体での売上げの総和は20億円になります）
［４］畑村洋太郎：「
失敗学の手法安全に生かせ」，朝日新聞，2006年6 月16日．
この記事で畑村氏は「バグを発見するためには、ほかに何が重要か？」という記者の質問に対して「単一の動作で試験するだけでなく、様々な動作を組み合わせたパターンをできる限り試す必要がある。自動車業界は、エンジン制御システムにバグがあると致命的事故につながるので、バグの発見に神経を使っている。実際の運転では考えられないような操作まで想定し、テストしている。」と答えています。
ソフトウェアの信頼性を高めて安全な生活を営むためには、フェイルセーフ的な設計をしておくことと単機能テストだけではなく、組合せテストを十分にすることなんでしょうね。本記事のエレベータ事故の件は、国土交通省の
ページも参考になります。
［５］NTT DoCoMo ：「
重要なお知らせ」，2006 年7 月24 日．
「メール新規作成やテキストメモ作成などの文字入力時に『みられまくっちゃ』などの文字を入力する際、最後の“ゃ”を入力すると、携帯電話が再起動する。」というバグの事例が載っています。IT PLUSによると、「
1047万台を修理」だそうです。
「かぜがなおりかけた」でも同様の現象になるそうなのでラムちゃん言葉全般がNGということではなさそうです。
原因については公開されていないので、分かりませんが、最後の“ゃ”を入力した直後、フリーズして、電源が落ちるということなので、仮名漢字変換の辞書データ（終端文字など）が壊れていたのかもしれませんね。
［６］Do Plaza：「
携帯電話の歴史」，2006 年10月19日．
日本の携帯電話の歴史は、1970年の大阪万博まで遡るという話です。
えーっと。2007年7月31日現在、私の使用しているメインの携帯電話は
N211iです。2001年12月に発売された機種なんですね。お財布ケータイ機能はもとより、カメラすら付いていません（でも、アンテナが伸びるぞ……って自慢にならないってば）。そろそろ、買い換えるかなぁ。不便は何も無いのだけれど。
ちなみにサブで使用している会社から支給された携帯は
F902iです。こちらは、2005年11月発売開始なのでそれほど旧くない？ピカピカなデザインとEdy機能が気に入っています。
「ソフトウェア開発規模の急増 -- 大規模化は進むが、人海戦術は解とならない」というページです。
グラフからは30倍を超える生産性の差があるように読み取れます。鶴保氏は「要員を10倍にすると生産性は3分の1になる」という発言をされていますが開発規模の問題と人の問題が混ざったグラフなので注意が必要と思います。
とはいえ、大規模ソフトウェアを効率よく開発するためには、独立して仕事ができる20人以下のチームを複数編成するのが良いのでしょう。そのために全体のアーキテクトが重要です。
また、板倉稔氏の研究によると、一般にソフトウェア規模が大きくなればなるほど、開発規模を過少に見積もる傾向にあるそうです。したがって、要求分析から開発規模を見積もる際の精度が問題となりますね。
［８］中鉢良治：「バグ頻発デジタル製品」，朝日新聞朝刊，2006 年4 月9 日．
「組み込みソフト」でバグが猛威を振るっているという記事です。「バグをつぶし切れずに製品化すると、さらにコストが膨らむ。消費者に販売ずみの製品、在庫品、生産ラインの仕掛かり品のすべてのソフトを修正しなければならないからだ。」と書かれています。また、「パソコン上のバグと比較して、TVなどの家電製品のバグについては、より欠陥品として消費者の信頼を失いかねない」ということが書かれています。
製品がアナログからデジタルに変わるなか、欠陥の出方もアナログ的な徐々に悪くなるものから、デジタル的なゼロイチで使えなくなるものへ変化しています。そういった欠陥の種類の変化が消費者にどう受け止められているのかの分析も必要ではないかと思います。
［９］國井秀子，石岡享也：「ブロードバンド時代のドキュメントシステムと画像機器」，JBMA 主催講演，2002 年，p.31
本講演は、リコーが提唱する「ドキュメントハイウェイ構想」の紹介と、その実現に向けての「ソフトウェア開発革新活動」の説明が中心となっています。
全部で68ページのドキュメントなのですが、「レビュー」と「再利用（部品化）」にかなりのページ数を割いています。レビューを上流へのシフトと位置付け、方法を工夫し、効果を定量化して経営者が成果を評価する（國井氏はリコーの常務執行役員）ということができているように思いました。
また、再利用（部品化）で最も苦労した点として、「ソフト技術者自身の『意識改革』と安易に行われるソフトへの仕様変更要求という『組織文化の打破』」をあげていらっしゃるのに感銘を受けました。
［10］NTT DoCoMo 社：「取扱い説明書 FOMA F901iS」，2005 年6月．
「HAYST入門」の20～26ページの例は、こちらの取扱説明書をもとに書かれています。
私は、携帯電話のマニュアルは必要に迫られた時にしか読まないので、このようなダウンロードサイトは本当に助かっています。
本当はマニュアル無しに直感で使え、失敗したり分からなかった時に適切なガイドが表示されるようなユーザフレンドリーな操作性を持っていることが重要なんですけどね。なかなかそこまで到達することはできません。
［11］ラリー・コンスタンチン：『ソフトウェア開発のカオス』，富野壽訳，共立出版，2003 年，p.44．
混迷を深めるソフトウェア開発に対する珠玉のエッセイ集です。
深い経験に裏付けられた言葉の数々はきっとあなたの問題解決のヒントになることでしょう。原題は「Beyond Chaos」であり、まさに、カオスを越えるための本なのですから。
［12］Noopur Davis，Julia Mullaney ：『The Team Software Process SM（TSPSM）in Practice : A summary of Recent Results』，
CMU/SEI，2003，p.38．
このレポートのCMMIレベルとKLOCあたりの欠陥数のグラフを引用しているのですが、Level 3の数字が間違っていました。
4.37件/KLOCではなく4.73件/KLOCですね。改訂（あるのか？）の時に直さなくては。
［13］D. Richard Kuhn，Dolores R. Wallace，Albert M. Gallo Jr.：
『Software Fault Interactions and Implications for Software Testing』，
IEEE Transactions on Software Engineering，vol. 30, No. 6, 2004．
ソフトウェアのバグがいくつの組合せによって発生しているかのデータ(FTFI = failure-triggering fault interaction)を示した論文です。直交表を用いたHAYST法や、Pairwiseによるテストが有効であることの根拠として紹介されることが多いものです。
注意すべきところは、"Because the effectiveness of combinatorial testing depends on the fact that a single test case can include a large number of pairs (or higher degree combination) of values, this approach may not be as effective for real-time or other software that depends on testing event sequences, but may be applicable to subsystems within real-time software."です。つまり、状態遷移やリアルタイム性を持つ部分に対しては効果がないかもしれないということです。ただし、その場合でもサブシステム単位では効果があるとまとめています。これは、私の経験とも合っています。
「HAYST入門」の10章に簡単に書いたように、状態遷移については遷移パスの網羅についても検討する必要があります。
［14］リー・コープランド（宗雅彦訳）：『はじめて学ぶソフトウェアのテスト技法』，日経BP 社，2005 年．
書名どおり、これからソフトウェアの「テスト技法」を勉強しようという人に最適な本です。この本に書いてあることは基本中の基本なのでテストエンジニアであれば知っていて当然のことばかりです。この本を読んでから、バイザーへ進むと良いと思います。
この本の各章は、「テストのプロセス、ケースステディの説明、同値クラステスト、境界値テスト、デシジョンテーブルテスト、ペア構成テスト、状態遷移テスト、ドメイン分析テスト、ユースケーステスト、制御フローテスト、データフローテスト、スクリプトテスト、探索的テスト、テストの計画、欠陥の分類、テストの終了判定」となっています。
「ペア構成テスト」の章では、直交表と、全ペアアルゴリズム(pairwise, All-pair)について記載されています。この章で、各種直交表が掲載されているWebページが載っていました。
第3章～第11章
直交表および、HAYST法について記述した章の参考文献です。
［15］秋山浩一：「HAYST 法の戦略的組織的展開と開発現場での効果実績」，
『2003 年品質工学研究発表論文』，品質工学会，2003年6 月，pp.142 ― 145．
HAYST法とその社内ツールについて社外に初めて公開した文章です。
ここから入手可能です。
このころから、組織展開（「HAYST入門」の第12章）について関心があったことがわかります。本論文では、
① 経営指標とのリンク
② イネーブラとしてのツール開発
③ 現場と一体となった活動
④ 底辺を広げる集合教育
⑤ 効果の確認とフィードバック
の5つを成功要因(KFS = Key factors for success)として挙げています。
なお、この発表大会でHAYST法の禁則回避アルゴリズムを開発した、山本訓稔氏がHAYST法の割り付け技法に関する論文「直交表を利用したSW製品評価（HAYST法の開発）」について発表しています。
直交表、交互作用表、線点図が多く掲載されているハンドブックです。[20]と内容はほとんど同じなのですが、わざとコピーに写らない水色を使用するなどの工夫がされています。
実験計画法（正確には「田口の実験計画法」）のバイブルです。基本的には実験の組み方の解説本ですが、HAYST法でも使用している多水準作成法、ダミー法などの割り付けテクニックが載っています。
直交表と線点図も巻末に多数掲載されていますので線点図が必要な方は下巻と合わせて参照ください。
［18］同上：「信号因子に対する目的機能の評価（1）」，『標準化と品質管理』，Vol. 52, No. 3～No. 7，1999年．
田口玄一氏がソフトウェアの評価の方法について述べた唯一の連載記事です。考え方など、非常に参考になります。
[19]にその一部が載っています。
テストエンジニアは図書館などで入手して読まれることを強くお勧めします。
[18]の5編の連載記事の内、2編が収録されています（他はハードウェア系の話ですが品質の作りこみの考え方としてとても参考になります）。
品質工学（タグチメソッド）が何か、その考え方を知りたい人は（分かりにくいですが）この本を一番初めに読むことをお勧めします（数式は飛ばして読んでも構いません）。やはり、田口玄一氏本人の書いたものを読むのが一番だからです。
直交表と、線点図、割り付けテクニックについて記載されています。恐らく、この本が一番多く、直交表・線点図を記載しているのではないかと思います。
何度も版を重ねているため[16]よりは入手しやすいようです。
品質工学（タグチメソッド）を適用して設計課題を解決する方法（計算方法を含む）を知りたい人はこの本が最適です。なぜなら、あの難解な計算式の意味が分かるように書いているからです。
第7章「7.2 直交表を利用したソフトウェア・デバッグ」にはHAYST法が紹介されています。
［22］山本訓稔：「直交表を利用したSW 製品評価」，『品質』，Vol. 34, No. 3，2004年．
日本品質管理学会の学会誌である『品質』へ掲載されたもので、HAYST法の仕組みについて記述されています。
本論文の「今後の課題」に「また、SWの多くは状態遷移を伴うシステムである。この領域に関してどれほど直交表が有効であるのかについては、未だ十分な検証ができていない。MDAなどにより設計がシステム化していることから、それらUMLなどで書かれた設計書から情報を取り出し、HAYST法や他の手法と組み合わせ、設計段階で並行してテスト設計を実現できるようにしたいと考えている。」と書かれていますが、その後、山本訓稔氏は、開発部門に異動し研究を重ね「
Model Checkingを適用した実践的非同期制御検証」を実現しました。
直交表によるソフトウェアテストについて、全く知らない初心者を対象に書いた記事です。
「HAYST入門」を読む前に、こちらでざっと内容を理解しておくとスムーズに読みこなせるかもしれません。
書名は「オブジェクト指向入門」ですが、960ページもあるこの本は、入門書というにはハードルが高い本です。しかし、その内容は、オブジェクト指向に携わる開発者のみならず、テストエンジニアも必読と言える内容です。
「契約による設計(Design by Contract)」の概念について参考にさせていただきました。
お勧めの一冊です。
［25］酒匂寛：『
課題・仕様・設計』，インプレスネットビジネスカンパニー，2003年．
テストエンジニアから「上流工程について勉強したい」と相談を受けた時に紹介する本です。
① 課題： 何を解決したいと思っているのか
② 仕様： 問題解決のために、どのようなシステムを用意すべきなのか
③ 設計： 求められるシステムを最適な形で構築するにはどうすればよいのか
について書かれており、上流工程の各フェーズで何をしなくてはならないのか、その役割が明確になります。
著者の酒匂寛氏は、[24]の翻訳者でもあります。
1979年に原著が出版されたとは思えないほどの名著です。ソフトウェアテストの本で本書を参照していない物は無く、まさに必読の一冊と言えるでしょう。冒頭の「プログラム・テストの心理学と経済学」の章で、MYERSはソフトウェアのテストが人と効率性の２つの面から論ずる必要があるとしています。それは、今でもソフトウェアテストを成功させるためのキーファクターです。
2006年に第2版が出版され、「エクストリーム・テスト」と「インターネット・アプリケーションのテスト」の章が増えました。
書名は「技法」となっているのですが、プログラムとテストに関する根本的な考え方や優れた示唆が多く、その価値は今後も変わることが無いでしょう（原題の"The Art of Software Testing"の方が本書の位置付けを正しく表しています）。
ホワイトボックステストについて勉強したい時にお勧めの一冊です。ただし、読みこなすのは大変です。
付録の「バグの統計と分類」を読むだけでもレビューの質があがると思います。
「HAYST入門」では、状態遷移パスを作るところで参考にしています。
[27]がホワイトボックステストについて書かれているのに対して、こちらは同著者がブラックボックステストに重点を置いて書かれている本です。
同値分割や境界値分析についてきちんと考えてみるきっかけになりますが、この本で理解するのはかなり大変です。
［29］大西建児，勝亦匡秀，加藤大受，佐々木方規，鈴木三紀夫，町田欣史，湯本剛，吉澤智美：『
JSTQB教科書』，翔泳社，2007年．
ソフトウェアテスト全般を勉強するために最適な本と思います。テストエンジニアとして配属されて半年くらい経った時に、自分の仕事がどういったものなのか知るために読むと効果的と思います。
もちろん、この本をしっかり勉強すればJSTQBのFoundation Levelに合格することが可能です。
ソフトウェアテスト業界の用語が氾濫（＆混乱）しないように、「HAYST入門」を書くにあたっては、できるだけこの本の（すなわちJSTQBの）用語にあわせるようにしました。
［30］Cem Kaner, Jack Falk, Hung Quoc Nguyen ：『
基本から学ぶソフトウェアテスト』，日経BP 社，2001年．
思い起こせば、この本の出版がきっかけになって、今日のソフトウェアテスト業界があるのではないでしょうか。
当時、ソフトウェアテスト関連の本といえば、[26], [27], [28], [38](旧版)と、「
ソフトウェア開発・検証技法」（松本正雄 、小山田正史、松尾谷徹）、「
The BUG」（鈴木裕信、加藤光明）、「
オブジェクト指向ソフトウェアテスト技法」（Ｓｉｅｇｅｌ，Ｓｈｅｌ、古宮誠一、広田豊彦訳）と、「
え～、全部テストするんですか!」（山村吉信）しかなく、テスト全般について勉強できる本は存在しなかったように記憶しています。
本書の素晴らしいところは実践的なところだと思います。何と言っても序文に「この本が対象にするのは、必ずしもみんながルールを守らない、または守るつもりがないときのテストの進め方だ。」と書いてあります。そう。それが知りたかったんだ！と膝をたたいた人も多かったことと思います。「HAYST入門」もこの精神を忘れないように書きました。
# 私もこの翻訳プロジェクトにちょっとだけ参加させていただき、非常に良い勉強になりました。
恐ろしいほど、実践的な本です。ノウハウを惜しみなく公開しています。
もし、まだ読んでいないなら、次のリンクをクリックして
目次だけでも良いから読んで欲しいと思います。
特に、「テストの自動化」をしようという人は、絶対に「第5章 テストの自動化」を読んでから取り掛かることをお勧めします。
おもしろくて、一気に読めてしまう本ではありますが、私は何度も読み返し、その度に新しい発見をしています。
テストというプロジェクトを管理する上で必要となる情報がまとめられています。
テスト計画書には何をどう書いたら良いのか、テストカバレッジについてどう考えたら良いのか、バグレポートの書き方とその管理方法はといった日常的なテストマネージャの仕事について書かれているのはもちろんのこと、動的な危機管理方法や、要員配置、政治的な振舞い方といった上級マネージャに必要なノウハウが詰まっています。
FMEAを使ったテスト分析についても多少触れられています。
[32]がテストマネージャに焦点を当てて書かれているのに対し、本書は、全てのテストエンジニア向けに書かれたテストプロセスの指南書です。
ケーススタディが示され、それに対する解と、チェックリストは十分実務的で役に立つものです。
ただ、読み進めるにはページ数が多く大変な苦痛を伴います。ケーススタディがもっとワクワク・ハラハラするようなストーリーになっていたら、楽しく読めるのになぁと、そこだけが惜しいです。
この本は、研修資料から生まれたものだそうで、テストの目標・戦略・戦術から始まり、リスク・ベーステスト、そしてテスト技法へと進みます。それぞれのテーマには、演習課題とその解説が付いているのでまさに「実践ワークブック」です。
「直交表と全ペア・テーブル」という章もあり、そこでは、明確に、「3つの値の組み合わせ、4つの値の組み合わせ、あるいはそれ以上の値の組み合わせによってバグが発生することはない、と想定するのです」と言い切っています。そして、「現実には、1回だけ3つの要素に関して特定の値を選択したためにバグが発生したことがあるが、当時の推測では、こうしたバグを確実に検出するためには、非常に高いコストをかける必要があり、利益以上にテストに資金を注ぎ込まなければならなかったでしょう。」と書いてあります。
要するに、リスクに対して順当な方法のひとつとして位置づけていました。
［35］Rick D. Craig, Stefan P. Jaskiel：『
体系的ソフトウェアテスト入門』，日経BP 出版センター，2004年．
正直に言うと、プロセスやテストマネジメントについて本を読み返すときに、[32], [33], [35]は、私の中では1冊の本なので、どこに書いてあったかなぁと結構迷います（で、結局全部あたることになり……それはそれで、都度新しい発見があるので良いのですが）。
でもって、この[32], [33], [35]の中で、1冊しか選べないとなると、この「体系的ソフトウェアテスト入門」をお勧めします。
この本が扱っている話題は広く、テスト技法についても記述されていますが、それはあくまでも管理者が理解しておくレベルにとどまっており、やはりテストマネージャの向けの入門書だと思います。
マインドマップを使いながらテスト設計のおもしろさを伝えている本です。
いわゆるベテランと呼ばれているテストエンジニアが頭の中で組み立てていることを、マインドマップを使用してテスト設計することに置き換えて、読者へ嫌味なく伝えることに成功しています。
この本を読んだ人が必ずテスト設計時にマインドマップを使用するようになるとまでは思いませんが、たとえ使用しなかったとしてもテストスキルという漠然とした技術はステップアップしているので、より良いテストになると思います。
本書では、ソフトウェアテストの意義を「お客様がソフトウェアを利用する上での『安心感を提供すること』」と定義しています。
「HAYST入門」の品質保証の定義に参考にさせていただきました。また、因子の発見にマインドマップが、水準の抽出にマンダラートがツールとして役に立つと考えています。
［37］Jr., フレデリック・P. ブルックス：『
人月の神話』，ピアソンエデュケーション，2002年．
"No silver bullet"（狼男を一撃で倒す銀の弾丸などない）という有名な言葉が書かれている本です。
さて、本書ではどう書いてあるか引用してみますと、「技術においても管理手法においても、それだけで十年間に生産性や信頼性と容易性での飛躍的な改善を一つでも約束できるような開発は一つとしてない。」とあります。そしてその理由として、ソフトウェアが持つ固有の性質である、複雑性・同調性・可変性・不可視性をあげています。
しかし、ブルックスは「それぞれの難しさが引き起こす問題は、しかし、改善できるものなのだ。」と述べています。そして、「おそらく今後は、登場しそうもない解決策を待っているのではなくて、ソフトウェア生産性において可能性のある漸増的な改善を進めていけるだろう。」とまとめています。
ソフトウェアエンジニアリングについて包括的かつ体系的に話題を取り扱っています。また、その内容は、たんなる紹介に終わるのではなく、基本的なところはきっちりと抑えてあります（教科書という感じですが、実践にも役立つものです）。
ソフトウェア開発者のみならず、テストエンジニアも、ソフトウェア開発というものを理解するためにご一読されることをお勧めします。
ソフトウェアの品質保証について最も勉強になった本です。内容は、著者の保田勝通氏が所属していた日立製作所での活動紹介を中心にISO9000と認証の問題から、オープン化への対応方針まで広く話題を取り扱っています。
1995年時点でこれらの考え方がまとまっていたのは、日本だけかもしれません。
今でも、品質保証について何か迷うとこの本に戻ることにしています。
ハードウェアの話なのですが、「設計」フェーズの品質獲得の話なので（生産フェーズの話ではないので）ソフトウェア開発でも十分参考になります。
特に、著者が考案したFMEAに代わるDRBFM(Design Review Basetd on Failure Mode)シートは、FMEAシートよりもソフトウェアの故障解析シートとして役に立ちます（シート自体はどちらを使用しても良いのですがDRBFMの考え方を知っておくことが重要です）。
ちなみに、GD3とは、"Good Design", "Good Discussion", "Good Design Review"の略です。
SWEBOK（スウェボック： Software Engineering Body of Knowledge）と略されることが多い本です。
ソフトウェアエンジニアリングの、知識体系すわわち、知識の概要と、文献リストから構成されています。
全体で12章から成り立っているのですが、その第5章が「ソフトウェアテスティング」にあてられています。そして、さらに、「ソフトウェアテスティングの基礎」、「テストレベル」、「テスト技法」、「テストに関係した計量尺度」、「テストプロセス」にブレークダウンされ、それぞれのトピックスで概要と論文へのポインタが示されるという具合です。
SWEBOKに対する最新情報は
Webから入手可能です。
アジャイルソフトウェア開発を正しく理解したい人にお勧めの一冊です。
TDDについてもかなり触れられています。「HAYST入門」ではテストファーストの概念を参考にさせていただきました。
後半になると、プログラミング知識が必要となるのですが、前半の「第1部 アジャイル開発」、「第2部 アジャイル設計」はプログラミングができなくてもOKです。特に第8章から第12章に示された以下の原則は重要です。
単一責任の原則（SRP）
オープン・クローズドの原則（OCP）
リスコフの置換原則（LSP）
依存関係逆転の原則（DIP）
インターフェース分離の原則（ISP）
全てのプログラマにとって有益な本と思います。この本に記された具体的なアドバイスに従うことこそ、高品質ソフトウェアへの一歩になるに違いありません。
なお、テストエンジニアは「第20章 ソフトウェアの品質」、「第22章 デベロッパーテスト」、「第23章 デバッグ」、「第27章 プログラムサイズが及ぼす影響」、「第30章 プログラミングツール」、「第34章 ソフトウェア職人気質とは」等々がある下巻の方が興味深く読み進めることができるかもしれません。
「HAYST入門」ではassert部分を参考にさせていただきました。
Java 2で行われた言語拡張について書かれた本です。
互換性を失う危険を冒してまで言語拡張を行う理由は、より、品質の良いソフトウェアを効率よく書くことができるようにするためです。したがって、テストエンジニアは言語拡張情報（新規言語を含む）に敏感になる必要があると考えています。
「HAYST入門」ではassert部分についてJavaの実装を確認するために参考にしました。
ガロア体、有限体を用いた直交表の作り方について書かれた本です。
この本を理解すると、素数と素数のべき乗を元にした、N水準系直交表（強さ２，３，４）を作ることができるようになります。
ただし、非常にやっかいな計算が必要となりますし、本に書かれていない原始規約多項式については、手が出ません（少なくとも私には）ので実際には、7水準系直交表の強度4までが限度かもしれません。
[45]と同じく、ガロア体、有限体を用いた直交表の作り方について書かれた本なのですが、少し易しく書かれています（でも数学が好きな人でないとつらいと思います）。
各種直交表を作るために、実際に必要となる知識は[45]レベルなのでステップとして読むという感じです。
直交表の数理と、暗号の数理が近いというのはおもしろいですね。
直交表の作り方と各種直交表が載っています。
第12章
HAYST法を上手く組織展開するためのノウハウについて記述した章の参考文献です。
SECIモデルとは、暗黙知と形式知を交互に循環させながら組織の知識レベルをスパイラルアップさせるという知識創造プロセスモデルです。
「HAYST入門」では、そのためには、基礎講座、実践道場、ツールの3点セットが不可欠としています。つまり、基礎講座で形式知を伝授し、実践道場の中で各組織の持つ暗黙知と専門家の暗黙知を引き出し、その結果をツールという形で究極の形式知に変換して展開を加速するという考えです。
知識を展開しレベルアップするためのノウハウが書かれています。
「HAYST入門」では新しい知識（ナレッジ）を組織展開するためには、5つの段階（ステージ）を踏むことが有効としていますが、そのプロセス構築の参考とした本です。
［50］ロバート・S.キャプラン，デビッド・P.ノートン（吉川武男訳）：『
バランス・スコアカード』，生産性出版，1997年．
バランススコアカードという経営品質改善手法のバイブルです。
「HAYST入門」では、組織の現状把握を高いレベルで行うためにバランススコアカードを使用することを提案しています。