ソフトウェア書籍一覧（日経BP）

　

ソフトウェア書籍一覧１０

｜　　　一覧９へ　　　|　　　書籍一覧目次へ　　　　|　　　トップページへ　　　|　　　一覧１１へ　　　｜


Amazon.co.jpで購入する cbook24.comで購入するソフトウエア書籍一覧　目次	ソフトウェアテスト２９３の鉄則 ISBN4-8222-8154-X　　日経BP出版センター原書：John Wiley「Lesson Learned in Software Testing : A Context-Driven Approach」ISBN0471081124 James Bach, Cem Kaner, Bret Pettichord　著テスト技術者交流会　訳 A5判　　327ページ　　本体価格\2.400　　2003年4月発売 [内容] 2001年11月に発売された「基本から学ぶソフトウェアテスト」の姉妹書。ソフト開発プロセスの「テスト」という切り口から、ソフトウェア技術者の仕事の進め方のポイントを、293の教訓としてすっきりと解説している。 [目次] 第1章テストという仕事鉄則001 プロジェクトの行く手を照らせ鉄則002 常に目的を意識せよ鉄則003 テストは幅広い顧客へのサービス業だと心得よ鉄則004 顧客の価値と向き合うこと鉄則005 重大なバグを素早く見つけよう鉄則006 プログラマとは二人三脚で進め鉄則007 口に出さなくても、いろいろ疑問を持とう鉄則008 プログラムの失敗を成功の母とせよ鉄則009 バグを全部見つけるのは無理だと心得よ鉄則010 テスト「完了」と聞いたら注意すべし鉄則011 テストで品質が保証できるなどと思うな鉄則012 門番になるな鉄則013 「私の仕事じゃありません」と言ってはならない鉄則014 プロセス改善グループには気軽に変身するな鉄則015 みんながテストを知っているわけじゃない第2章実践的テスト担当者の思考法鉄則016 認識論を駆使すること鉄則017 認識論の手法を使ってテストを鋭くする鉄則018 認知心理学も駆使する鉄則019 テストは思考の産物だ鉄則020 テストには推理力が必要となる鉄則021 技術的、創造的、批判的、実践的な思考が優れたテストのカギ鉄則022 ブラックボックステストは「何も考えていないテスト」ではない鉄則023 漫然と操作することはテストとは呼ばない鉄則024 テストは質問の答えを探す作業である鉄則025 モデリングはテストの決め手だ鉄則026 直感は糸口として有用だが、判断の根拠に使ってはならない鉄則027 テストとは探求することだ鉄則028 探求のためには三つの思考法がある鉄則029 仮説的推論の技法を使え鉄則030 推論と反証の方法論で製品を評価せよ鉄則031 本当の「要求仕様」は何かを把握せよ鉄則032 要求仕様書をあてにするな鉄則033 明文化されていない仕様もあることに気を付けよ鉄則034 「動いた」の本当の意味を確認せよ鉄則035 結局、テスト結果は製品に対する「印象」に過ぎない鉄則036 「テスト」と「テストをする」ことを混同してはならない鉄則037 複雑なテストは速攻の繰り返しでこなせ鉄則038 テストのアイデアがすぐ欲しいとき、経験則が役に立つ鉄則039 思い込みから逃れられなくても、上手く付き合うことはできる鉄則040 騙されやすいと自覚することが騙されない秘訣鉄則041 たまたまか、当然の結果か、そこを見分けよ鉄則042 混乱をテストに生かすべし鉄則043 慣れは見落としの素、新鮮な眼をいつも絶やさずに鉄則044 手順に従うのではなく、手順を従わせる鉄則045 「1287 文字入力せよ」などと書いてはいけない鉄則046 テスト技術者の成長もテストの成果の一つである鉄則047 習うだけではテストの達人にはなれない第3章テストの技法鉄則048 テストの五大要素をいつも念頭に置け鉄則049 人に着目したテスト技法は、誰がテストするのかがポイント鉄則050 網羅性（カバレッジ）に着目した手法は、どこまでテストするかがポイント鉄則051 問題に焦点をあてた技法は、どんなリスクがあるかがポイント鉄則052 作業に焦点をあてた技法は、どうテストするかがポイント鉄則053 合否判定に焦点をあてた技法は、合否の判断基準がポイント鉄則054 テスト技法の分類は、各人の捉え方によって変わる章末付録入力フィールド用のテストマトリクスを作成する方法繰り返し発生する問題用のテスト一覧の作成方法仕様に基づくテストに利用するトレーサビリティマトリクスの作成方法全ペア技法を用いた組み合わせテストの実施方法プログラムの構成要素やさまざまな側面に関連するリスクの分析方法訳者補足直交表を用いた全ペアのテストケースの作成例第4章バグの報告鉄則055 報告の内容でテストをした“人”がわかる鉄則056 正しく伝えてこそ修正がなされる鉄則057 障害レポートを商売道具として活かせ鉄則058 障害レポートはテスト実施者の名刺である鉄則059 障害レポートの価値を高めるための、手間暇を惜しむな鉄則060 誰でもバグを報告できることが大切鉄則061 他人の障害レポートの書き換えは安易にやるな鉄則062 期待に合わない品質もバグとして扱え鉄則063 テストを担当したら、バグ報告できない人たちの代弁者となれ鉄則064 修正に難色を示されそうなバグは、関係者の注意を引くように障害レポートを書け鉄則065 障害管理システムをプログラマの評価に使うな鉄則066 障害管理システムをテスト実施者の評価にも使うな鉄則067 バグの報告は新鮮さが大切鉄則068 目立つから報告されているという思い込みは危険鉄則069 設計の不具合を検出するのもテストの目的鉄則070 極端な条件でのバグはセキュリティ上の潜在的なリスク鉄則071 重箱の隅をつつけ鉄則072 修正に値しないバグはない鉄則073 優先度と重要度を区別せよ鉄則074 バグの外見に惑わされるな鉄則075 些細なコーディングエラーを見つけたならテストを追加せよ鉄則076 再現しないエラーも全て報告せよ。時限爆弾になる恐れがある鉄則077 再現できないバグはない鉄則078 障害レポートの処理コストにも注意を払え鉄則079 ツールや環境関連バグへの感度を上げよ鉄則080 バグ報告の前に、プロトタイプや非公式プログラムでないかを確認せよ鉄則081 重複した障害レポートは問題解決促進剤になる鉄則082 障害レポートは1 件1 葉鉄則083 障害レポートはタイトルで決まる鉄則084 バグをありのままに報告せよ鉄則085 問題点をはっきり報告し、解決策は書かない鉄則086 誰が読むか分からない。言葉使いには十分注意すること鉄則087 疲労困ぱいで不機嫌な人に読まれると思え。報告書は極力読みやすく鉄則088 報告のスキルアップに努めよ鉄則089 必要なときは、マーケットデータやサポートデータを活用せよ鉄則090 障害レポートをクロスレビューせよ鉄則091 相手に直接会っておこう鉄則092 ときには障害を実演してみせる鉄則093 「直した」と言われたら、別の所に問題が出てきていないか確認せよ鉄則094 バグ確認は鮮度が命鉄則095 修正が失敗していたらプログラマと直接話し合おう鉄則096 障害レポートに終止符を打つのはテスト担当者の役割鉄則097 すべてのバグ修正を強制するな。戦いの場は選ぶべきだ鉄則098 保留したバグを消失させるな鉄則099 バグ修正をテストがうまくできない理由にするな鉄則100 バグ保留判定への抗議は即座に行え鉄則101 戦うときは、必勝の決意で戦え第5章テストの自動化鉄則102 目的はコストダウンではない、開発プロセスの迅速化だ鉄則103 同じことの繰り返しではなく、手法を変えて深堀りせよ鉄則104 状況に応じて自動化の戦略を選択せよ鉄則105 自動化は“銀の弾丸”にはならない鉄則106 テストツールに使われるな鉄則107 ゴミクズを自動化しても意味はない鉄則108 手動テストと自動テストを同格に扱うな鉄則109 同じテストを何度も繰り返せるだけではモトは取れない鉄則110 回帰テストを自動化しただけではバグは出ない鉄則111 自動化で埋もれてしまうバグもある鉄則112 自動テストの失敗のツケは忘れた頃にやってくる鉄則113 テスト記録の再生は思うようには機能してくれない鉄則114 テストツールにもバグはつきもの鉄則115 ユーザインタフェースは変わるためにある鉄則116 GUI テストツールは、互換性と習得性とサポートで選べ鉄則117 自動化した回帰テストはすぐに陳腐化していく鉄則118 テストの自動化はソフトウェア開発そのものである鉄則119 テストの自動化は決して安くない投資である鉄則120 テストの自動化に必要なのは、プログラミング、テスト、プロジェクト管理のスキル鉄則121 自動化の検証にはパイロットプロジェクトを利用せよ鉄則122 テストの自動化はテスト側と開発側との協調が必要である鉄則123 自動化テスト環境の開発にはレビューを活用せよ鉄則124 自動化テスト設計に手抜きは厳禁鉄則125 テストスクリプトは簡潔をモットーとせよ鉄則126 反復コードを避けるためだけにテストライブラリを構築するな鉄則127 テスト変数の多さに閉口したときは、データ駆動型自動テストを使え鉄則128 プログラマ以外ならキーワード駆動型自動テストが最適鉄則129 入力データを自動生成するにはコツがある鉄則130 テストツールはデータと処理とを分離せよ鉄則131 汎用的スクリプト言語を使え鉄則132 自動化のためにはプログラミングインタフェースを活用しろ鉄則133 単体テスト環境をぜひ作れ鉄則134 テストを理解していないプログラマには要注意鉄則135 テストを軽んじる者にはテストツールは作れない鉄則136 自動化よりテスト容易性を上げることにまず投資せよ鉄則137 「テスト容易性」とは可視性と操作性である鉄則138 テストの自動化計画はプロジェクトの早い段階に立てる鉄則139 自動化専門チームはできることを明確に文書で示せ鉄則140 即効性のある自動化から始めよ鉄則141 まず自らの道具箱を見直せ第6章テストドキュメント鉄則142 問題を見据えた上で対策を打て鉄則143 テンプレートはそれが必要ない上級者にしか使いこなせない鉄則144 コミュニケーションを首尾一貫させるにはテンプレートも役立つ鉄則145 IEEE 829 標準規格も使い方次第鉄則146 IEEE 829 標準規格の問題点を理解せよ鉄則147 はじめに要件分析ありき、たとえテストでも鉄則148 テストドキュメントの要件分析に役立つチェックリストを覚えておこう鉄則149 テストドキュメントの核となる要件を最大三つに集約した要約文を作ってみよう第7章プログラマとの協同作業鉄則150 プログラマの考え方を理解せよ鉄則151 プログラマから信頼を勝ち得よ鉄則152 プログラマとは共存共栄であれ鉄則153 自らの誠実さと能力を示さずに技術的信頼関係など築けない鉄則154 バグを憎んで人を憎まず鉄則155 プログラマとは人にモノを教えるのが好きな人種である鉄則156 テストの容易さはプログラマの責任第8章テストプロジェクトのマネジメント鉄則157 「サービス」文化を創り上げよ鉄則158 「管理」文化にするな鉄則159 情報発信の網を張りめぐらせろ鉄則160 対象をテストプロジェクトに絞り込め鉄則161 プロジェクトを正しい方向に進化させよ鉄則162 要求は常に変更されるものだと心得よ鉄則163 機能、信頼性、時間、コストの間のトレードオフ関係に注意しろ鉄則164 ライフサイクルをプロジェクトマネージャに選択させよ鉄則165 ウォータフォールモデルでは信頼性と時間が対立する鉄則166 エボリューショナリライフサイクルでは機能と時間が対立する鉄則167 開発初期段階にリソースを積極的に投入せよ鉄則168 カスタムソフトとパッケージソフトの開発は違う鉄則169 テスト容易性のための機能を要請せよ鉄則170 ビルドスケジュールを調整せよ鉄則171 ビルド引き渡し前のプログラマの仕事を把握せよ鉄則172 ビルドの受け入れ準備は怠るな鉄則173 ときにはビルドのテスト受け入れを拒否することも大切だ鉄則174 まずはスモークテストで判断せよ鉄則175 テストを中止しソフトウェアを書き直した方がよいこともある鉄則176 郷に入れば郷に従え鉄則177 プロジェクトドキュメントは絵空事であることを念頭に置け鉄則178 使わないなら詳細仕様を求めるな鉄則179 情報の引き出しは多く持て鉄則180 プロジェクトマネージャに構成管理の問題を気付かせろ鉄則181 プログラマはまるで竜巻のようなもの鉄則182 後工程の変更を容易に取り込めてこそ良いテスト計画である鉄則183 レビュー準備と同時にテスト準備も行え鉄則184 どのくらいテストをすればよいかという質問に解はない鉄則185 「充分なテスト」とは「正しい状況判断を下すのに充分な情報を得られること」である鉄則186 テストサイクルが２回程度で終わると思うな鉄則187 個々のタスク工数を積み上げて、全体スケジュールを見積もる鉄則188 作業時間は担当者に見積もらせるべきである鉄則189 テストの担当者と開発者の人員の比率に正解はない鉄則190 適材適所を心がけよ鉄則191 担当機能をローテーションさせよ鉄則192 ペアテストを試みよ鉄則193 バグ探しの達人をプロジェクトに入れろ鉄則194 テスト前に、テスト方針を示せ鉄則195 テストの集中時間を設けよ鉄則196 テスト作業を邪魔する割り込みを把握するため作業記録をつけよ鉄則197 定期的な進捗報告は強力なテストツールだ鉄則198 数字しか見ない経営陣ほど危険なものはない鉄則199 バグ総数によるプロジェクト進捗測定はするな鉄則200 カバレッジも使い方による鉄則201 進捗報告にバランススコアカードを適用せよ鉄則202 週報はこう書け鉄則203 プロジェクトダッシュボードで進捗状況を分かりやすく示せ鉄則204 適切に設定してこそマイルストーン毎での状況報告は有効となる鉄則205 リリースの最終判断はプロジェクトマネージャにさせる鉄則206 製品リリースの際にはコメントを付け加える鉄則207 リリースレポートには意見でなくテスト結果を記載せよ鉄則208 最終リリースレポートには未修正のバグリストを付けよ鉄則209 批評家が批判に使う10 の悪い事柄をリストアップしたリリースレポートを書いてみよ第9章テストグループのマネジメント鉄則210 没個性の行き着くところは無気力充満の職場である鉄則211 部下を一人の経営者として扱え鉄則212 部下の障害レポートに目を通せ鉄則213 部下を一人の経営者として評価せよ鉄則214 状況を知りたければ一緒にテストしろ鉄則215 「かけもち」はできそうでできない鉄則216 専門家としての知見を身に付けられれば、「できる」部下が育つ鉄則217 テストのプロは、関連技術の知見も磨け鉄則218 バリバリ働き、スキルを磨け鉄則219 技術サポートのログを見直せ鉄則220 新人のスタートを後押しせよ鉄則221 新人はまずドキュメントのチェックから鉄則222 基本操作のテストで製品に慣れさせる鉄則223 障害レポートは新規より過去のレポートの書き直しから鉄則224 新規バグより過去のバグの再テストから鉄則225 プロジェクトの終盤に初心者を投入するな鉄則226 スタッフの士気こそ貴重な財産鉄則227 自分をいじめるな鉄則228 部下を残業で苦しめるな鉄則229 部下を虐待から守れ鉄則230 教育の機会を与えよ鉄則231 採用の決断が一番重要鉄則232 外注でとりあえず息をつなぐ鉄則233 はみ出し者はめったに受け入れるな鉄則234 必要なスキルを持つ者を必要なポジションに鉄則235 テストチームには多種多様な人員構成を鉄則236 雇えば使えるこんな人々鉄則237 メンバに受け入れられる人を採用しよう鉄則238 仕事を大切にする人を採用しよう鉄則239 誠実な人を採用しよう鉄則240 採用面接では実技試験を行え鉄則241 パズルでテストへの適性は計れない鉄則242 採用時には過去の実績を確認せよ鉄則243 採用を決めたら迅速に処理せよ鉄則244 無責任な口約束は厳禁第10章ソフトウェアテストにおけるキャリア鉄則245 将来の姿を見据えてキャリアを積め鉄則246 プログラマより高収入を狙え鉄則247 枠にとらわれずキャリアを追求せよ鉄則248 キャリアは自らで築け鉄則249 テスト以外のキャリアへ進め鉄則250 会社以外の場所でキャリアを伸ばせ鉄則251 外部会議は人脈の宝庫鉄則252 他社も苦労している鉄則253 今の会社がイヤなら他を探せ鉄則254 自らの地位を賭す状況に備えよ鉄則255 働きたい企業をリストアップせよ鉄則256 自身のポートフォリオを準備せよ鉄則257 履歴書を販売用ツールとして使いこなせ鉄則258 コネを活かせ鉄則259 給料の水準を知れ鉄則260 求人広告に自分を合わせろ鉄則261 面接は場数も大事鉄則262 ここぞと思う企業はとことん調べよ鉄則263 面接では臆するな鉄則264 ポジションを獲得するための交渉術に長けよ鉄則265 採用権は誰にあるかを考慮せよ鉄則266 Perl を学べ鉄則267 Java かC++を学べ鉄則268 世の中のテストツールを知っておくこと鉄則269 文章力を磨け鉄則270 プレゼン能力を磨け鉄則271 資格取得について考えよ鉄則272 ２週間でとれた黒帯など実戦では使えない鉄則273 ソフトウェア技術者ライセンスを取得することに価値があるかを見極めよ第11章テスト戦略の立案鉄則274 三つの質問を携えてテスト戦略を立案せよ鉄則275 一つの選択肢にとらわれてテスト戦略を立案するな鉄則276 テストの進め方の指針をまとめたものがテスト計画である鉄則277 テスト計画は状況に合わせるべし鉄則278 テスト計画は戦略、段取り、成果物の三位一体と心得よ鉄則279 目先の作業に追われて戦略を見失うな鉄則280 テストケースの項目数からは何も分からない鉄則281 テスト戦略はテスト項目より重要だと心得よ鉄則282 テストの質は戦略に左右されると肝に銘じろ58 鉄則283 多様的ほどほどの原則でテストする鉄則284 テスト戦略を実践するためにリソースを揃えるべし鉄則285 最初の戦略はいつも間違っていると思え鉄則286 「どうすればより良いテストができるか」を常に問い続けよ鉄則287 製品の成熟度に応じてテストせよ鉄則288 テストをレベルに分けて作戦をたてろ鉄則289 グレーボックステストを実施せよ鉄則290 古いテストの再利用には注意しろ鉄則291 人が変われば見方も変わると心得よ鉄則292 プロジェクトのリスクもテスト戦略に組み込め鉄則293 テストサイクルをテスト作業の鼓動とみなせ章末付録１コンテキスト駆動型テスト計画 1.テスト計画上の主要な課題を監視する 2.目的を明確にする 3.製品を分析する 4.リスクを分析する 5.テスト戦略を立てる 6.段取りを決める 7.テスト計画を共有する章末付録２「良いテスト計画」の構成要素用語と概念テスト計画の役割テスト計画の品質基準テスト計画の経験則付録ソフトウェアテストに対するコンテキスト駆動型アプローチ参考文献訳者あとがき索引
Amazon.co.jpで購入する cbook24.comで購入するソフトウエア書籍一覧　目次	基本から学ぶソフトウェアテストテストの「プロ」を目指す人のために ISBN4-8222-8113-2　　日経ＢＰ出版センター原書：John Wiley「Testing Computer Software 2/E」 JackFalk, CemKaner, Hugn Quoc. Nguyen　著テスト技術者交流会　訳 B5変型判　　500ページ　　本体価格\4,500 　　01/11/22発売 [内容] 世界で最もたくさん読まれているソフトウェアテスト/品質保証の実践的な教科書。テストの基本から実践的なテストのスキル、テストプロジェクトの管理まで、ソフトウェア開発の現場に即したノウハウがふんだんに盛り込まれている。プロフェッショナルの技を極めて最強のテスト担当になろう！ [目次] 基本編・テストの進め方・テストの目的と限界・テストの種類と位置付け・ソフトウェアエラー・障害の報告と分類テスト技術各論・障害管理システム・テストケースの設計・プリンタ（およびその他のデバイス）のテスト・ローカライゼーションテスト・ユーザマニュアルのテスト・テストのツール・テストの計画とドキュメントテストプロジェクトやテストチームの管理・開発全体におけるテストの役割・ソフトウェアの不具合に対する法的責任・テストチームの管理
Amazon.co.jpで購入する cbook24.comで購入するソフトウエア書籍一覧　目次	ソフトウェア開発 201の鉄則 ISBN 4-8222-9002-6　　　日経BP社原書：IEEE「201 Principles of Software Development」Alan M.Davis アラン M. デービス　著松原友夫　訳四六判　　 240ページ　本体価格\1,553　　1996年3月25日発売［内容］　IEEE Software の現編集長である著者が、コンピュータ・ソフトウェアを開発する際に誰もが悩む作業工程、品質確保、人員構成等のさまざまな問題にズバリ答える。現場のソフトウェア技術者、管理者はもちろん、学生、研究者にとっても必携のガイドブック。［目次］第１章　序章第２章　一般原理原理１　品質第一原理２　品質の定義は見る人によって異なる原理3 　生産性と品質は不可分である原理4 　高品質のソフトウェアは不可分である原理５　品質を後からとってつけるようなことはするな原理6 　信頼性が低いソフトウェアは性能が悪いソフトウェアより手に負えない原理7 　製品のプロトタイプを早めに顧客に納入せよ原理8　顧客やユーザーとよく話し合え原理９　開発者と顧客の見返りを合わせよ原理10 　1つは放棄するつもりでいよ原理11　適切な型のプロトタイプを開発せよ原理12　プロトタイプに適切な機能を組み込め原理13　使い捨て型のプロトタイプは手早く作れ原理14 　システムを斬新的に成長させるように計画せよ原理15 　見れば見るほどもっとよいものが欲しくなる原理16 　開発期間中の変更は避けられない原理17 　可能なら開発するより購入せよ原理18 　ユーザー用のマニュアルが短くて済むようにソフトウェアを作成せよ原理19 　どんな複雑な問題にも解決策はある、と思うのは誤り原理20 　仮定を記録せよ原理21 　異なるフェーズには異なる言語を原理22 　ツールを使う前に技法を学べ原理23 　ツールを使え, ただし現実的に原理24 　ソフトウェア・ツールを優れた技術者に与えよ原理25　 CASEツールは高価である原理26　「いつ使うかを知る」ことはどう使うかを知ることと同じくらい重要だ原理27 　目標を達成したらそこで止めよ原理28 　形式的手法を知れ原理29 　組織の評価と個人の評価を合わせよ原理30 　レミング（一時の流行）には心して従え原理31 　新技術を無視するな原理32 　文書化規格を使え原理33 　どの文書にも用語集が必要だ原理34 　どの文書にも索引が必要だ原理35 　同じ概念には同じ名称を使え原理36 　研究が終わってからの技術移転はうまくいかない原理37 　責任をとれ第３章　要求分析の原理原理38 　いいかげんな要求仕様からはいいかげんなコスト見積もりしかできない原理39 　要求仕様を書く前に問題を特定せよ原理40 　要求について今できることは何でもやれ原理41 　今すぐ要求仕様書の誤りを直せ原理42 　プロトタイプはユーザー・インターフェース選択のリスクを減らす原理43 　なぜこの要求項目が含まれたかを記録せよ原理44 　サブセットを識別せよ原理45 　要求を審査せよ原理46 　要求分析段階で設計するな原理47 　正しい技法を使え原理48 　要求を複数の視点から見よ原理49 　要求仕様書を賢く編成せよ原理50 　要求に優先順位をつけよ原理51 　簡明に書け原理52 　どの要求項目にも別々に番号を付けよ原理53 　曖昧な要求記述を減らせ原理54 　自然言語を増やし、決して置き換えるな原理55 　より形式的なモデルを作る前に自然言語で書け原理56 　要求仕様書を常に読みやすくしておけ原理57 　信頼性について特に規定せよ原理58 　環境が「受け入れ可能な」条件を満たさない場合について規定せよ原理59 　未決項目は自己消滅させる注記と共に記述せよ原理60 　要求仕様書をデーターベースに格納せよ第4章設計の原理原理61 　要求仕様から設計への移行は容易ではない原理62 　設計から要求項目を追跡せよ原理63 　代替案を評価せよ原理64 　文書のない設計は設計とは言わない原理65 　カプセル化せよ原理66 　同じものを何度も発明するな原理67 　単純に作れ原理68 　特殊なケースをあまりたくさん作るな原理69 　知的な距離を最小にせよ原理70 　設計を知的コントロールの下に置け原理71 　概念の完結性を維持せよ原理72 　概念上の誤りは文脈上の誤りよりも重大である原理73 　カップリングとコヒージョンを使え原理74 　変更が容易なように設計せよ原理75 　保守が容易なように設計せよ原理76 　エラー修正が容易なように設計せよ原理77 　ソフトウェアに普遍性を組み込め原理78 　ソフトウェアに柔軟性を組み込め原理79 　効率のよいアルゴリズムを用いよ原理80 　モジュール仕様書にはユーザーが必要な情報はすべて書き、それ以外は書くな原理81 　設計は多次元的だ原理82 　優れた設計は優れた設計者が創り出す原理83 　アプリケーションを知れ原理84 　巨額の投資をしないでも再利用ができる原理85 　「ガーベッジ・イン、ガーベッジ・アウト」は正しくない原理86 　ソフトウェア信頼性は冗長性を与えることで達成できる第5章コーディングの原理原理87 　トリックを使うな原理88 　グローバル変数を使うな原理89 　トップダウンで読めるように書け原理90 　副作用を避けよ原理91 　意味のある名称を使え原理92 　人のことを第一に考えてプログラムを書け原理93 　最適なデーター構造を使え原理94 　それを速くする前に正しいものにせよ原理95 　コードを仕上げる前にコメントを加えよ原理96 　コーディングを始める前に文書化せよ原理97 　すべてのコンポーネントを机上デバッグせよ原理98 　コードを細かく審査せよ原理99 　構造化機能のない言語でも使うことができる原理100 　構造化されたコードは必ずしもよいコードではない原理101 　深い入れ子を作ってはいけない原理102 　適切な言語を使用せよ原理103 　プログラミング言語を言い訳にしてはならない原理104 　言語についての知識はそれほど重要ではない原理105 　プログラムの体裁を整えよ原理106 　すぐコーディングを始めるな第6章テスティングの原理原理107 　テスト項目を要求項目と関係づけよ原理108 　テストを行なう時期よりずっと前にテストを計画せよ原理109 　自分のソフトウェアを自分でテストするな原理110 　自分のソフトウェアのテスト計画を自分で作成するな原理111 　テスティングは欠陥の存在をあらわにする原理112 　エラーだらけのソフトウェアは価値がないことを保証するが、かといってエラーがないこと原理113 　エラーを見つけてこそテストがうまくいったと言える原理114 　半分のエラーは15%のモジュールで発見される原理115 　ブラックボックス及びホワイトボックス両方のテスティングを用いよ原理116 　テストケースには期待される結果を含めよ原理117 　無効な入力をテストせよ原理118 　常に過負荷状態のテストをせよ原理119 　宇宙爆発起源説は当てはまらない原理120 　McCabeの複雑性尺度を使え原理121 　効果的なテスト完了尺度を使え原理122 　テスト・カバレッジを効果的に達成せよ原理123 　単体テスティングが済む前に統合するな原理124 　ソフトウェアに仕掛けを組み込め原理125 　エラーの原因を分析せよ原理126 　エラーを個人のもにするな第７章　管理の問題原理127 　優れた管理は優れた技術より重要だ。原理128 　適切な解決策を用いよ原理129 　読んだことのすべてを信じるな原理130 　顧客の優先順位を理解せよ原理131 　人材こそ成功の鍵だ原理132 　少数精鋭はスキルの低い人々による人海戦術よりずっとよい　原理133 　部下の話をよく聞け原理134 　部下を信頼せよ原理135 　素晴らしい仕事を期待せよ原理136 　うまく話し合う技術は必須である原理137 　水運びの仕事をせよ原理138 　人は思いもよらない動機で仕事をしている原理139 　オフィスを静かに保て原理140 　人員と時間は交換できない原理141 　ソフトウェア技術者の能力差は大きい原理142 　望んだ目標に最適化できる原理143 　押し付けがましいデータの集め方をするな原理144 　１台あたりのコストは役に立たない原理145 　生産性を計測する完全な方法はない原理146 　特別誂えのコスト見積もりモデルを作れ原理147 　非現実的な完成予定日を設定するな原理148 　不可能なことをするな原理149 　数える前に知れ原理150 　生産性データを収集せよ原理151 　チームの生産性を忘れるな原理152 　人月あたり行数は言語に関係しない原理153 　日程を信じよ原理154 　性格に積み上げられたコスト見積もりでも正しいとは限らない原理155 　日程を定期的に見直せ原理156 　少しくらいの過小見積もりは常に悪いとは限らない原理157 　適切な資源を割り当てよ原理158 　プロジェクトを詳細に計画せよ原理159 　計画を常に更新せよ原理160 　増幅する波のような計画変更の繰り返しをするな原理161 　上位１０のリスク項目を知れ原理162 　直面するリスクを理解せよ原理163 　適切なプロセス・モデルを使え原理164 　手法はあなたを救いはしない原理165 　奇蹟的な生産性の向上には秘密はない原理166 　進歩が何を意味するかを知れ原理167 　計画とのずれを管理せよ原理168 　ハードウェアに過大な負荷をかけるな原理169 　ハードウェアの進化には楽天的であれ原理170 　ソフトウェアの進化には悲観的であれ原理171 　大混乱など起こるはずがないという考えがしばしば大混乱をもたらす原理172 　プロジェクトの事後検討会（または反省会）を実施せよ第8章製品保証の原理原理173 　製品保証は贅沢ではない原理174 　ソフトウェア構成管理手順を早期に確立せよ原理175 　SCMをソフトウェア・プロセスに適応させよ原理176 　SCMをプロジェクト管理を独立になるように組織化せよ原理177 　開発と製品保証の仕事を回転させよ原理178 　すべての中間成果物に名称とバージョン番号を与えよ原理179 　基準品目を制御せよ原理180 　すべてを保存せよ原理181 　すべての変更を追跡し続けよ原理182 　変更制御を抜かしてはいけない原理183 　変更要求にランクをつけ日程を立てよ原理184 　大規模な開発には検証と妥当性の確認(V&V)を用いよ第9章進化の原理原理185 　ソフトウェアは変化し続ける原理186 　ソフトウェアのエントロピーは増加する原理187 　壊れていないのなら直すな原理188 　現象を直すのではなく問題を直せ原理189 　最初に要求仕様を変更せよ原理190 　リリース前のエラーはリリース後のエラーを生む原理191 　プログラムが古ければ古いほど保守するのが難しくなる原理192 　言語は保守性に影響を与える原理193 　ときには始めからやり直す方がいい場合がある原理194 　最悪のコンポーネントを最初に作り直せ原理195 　保守は開発よりも多くのエラーを作り込む原理196 　変更した後には必ず回帰テストを行なえ原理197 　この変更は簡単だという信念が正しくない変更をもたらすことが多い原理198 　構造化されていないコードを構造化してもそれが改善されるとは限らない原理199 　最適化する前にプロファイラーを使え原理200 　親しさを維持せよ原理201 　システムの存在そのものが進化を促進する
Amazon.co.jpで購入するソフトウエア書籍一覧　目次	ソフトウェアテスト技法～自動化、品質保証、そしてバグの未然防止のために～ ISBN 4-8227-1001-7　　　日経BP社原著 Software Testing Techniques (2nd Edition) ボーリス・バイザー　著小野間彰、　山浦恒央　訳 B5変型判　　468ページ　　価格（本体5,340円+税）　1994年1月1日発売［内容］　品質の鍵となるユニットレベルでのテスト技法について詳細に解説した、教科書の決定版です。年々進歩するテスト技術体系の中からとくに効果の高い技法を選び、この分野の第一人者である著者が実践の知恵と経験則を加味してまとめ上げた力作です。米国では、「プログラムテストのバイブル」として広く読まれ、業界・学界関係者の座右の書となっています。［目次］＜第１章　はじめに＞テストの目的、両極の比較、テストのモデル、ビリヤードとオラクル、完全なテストは可能か＜第２章　バグの分類＞要点、バグの影響度、バグの分類法、バグの統計、まとめ＜第３章　フローグラフとパステスト法＞要点、パステスト法の基礎、述語,パス記述,可達パス、パスの造影、パス追跡機構、実現方法とパステスト法の応用、テスト可能性についてのヒント、まとめ＜第４章　トランザクションフローテスト法＞要点、概要、トランザクションフロー、トランザクションフローテスト法、実現方法へのコメント、テスト可能性のヒント、まとめ＜第５章　データフローテスト＞要点、データフローテストの基本、データフローテスト法、アプリケーション, ツール, 効果、テスト設計上のメモ、まとめ＜第６章　ドメインテスト＞要点、ドメインとパス、簡潔なドメインと複雑なドメイン、ドメインテスト、ドメインとインタフェーステスト、ドメインとテスト可能性、まとめ＜第７章　メトリックスと複雑性＞要点、メトリックスとは何か、語句的メトリックス、構造的複雑性、ハイブリッドメトリックス、メトリックスの実現方法、テストとメトリックス、まとめ＜第８章　パス, パス積, 正規表現＞要点、方針、パス積とパス式、パスの簡略化、応用、正規表現とフロー変則の摘出、まとめ＜第９章　構文テスト＞要点、なぜ, 何をどうするか、文法、構文テストの実行と応用、テスト可能性のヒント、まとめ＜第１０章　論理テスト＞要点、動機的概要、デシジョンテーブル、パス式再考、ＫＶ図、仕様、テスト可能性のヒント、まとめ＜第１１章　状態, 状態のグラフ表現, 遷移テスト＞要点、動機的概要、状態グラフ、よい状態グラフとわるい状態グラフ、状態テスト、テスト可能性のヒント、まとめ＜第１２章　グラフ行列と応用＞要点、技術的動機の概要、グラフの行列、関係、行列のべき乗、ノード削減法、ツールの作成、まとめ＜第１３章　実現方法＞要点、概要、プログラマの戦略、テスト担当者の戦略、製品としてのテスト、ツール＜付録　バグの統計と分類＞［著者紹介］ボーリス・バイザー（Boris Beizer）ペンシルベニア大学でコンピュータ・サイエンスのPh.Dを取得。30年以上にわたり，ソフトウエアの検証，品質管理，性能評価モデル，性能測定，システムアーキテクチャの分野で，ソフトウエアコンサルタント，著述家，研究者，セミナー講師として活動。ソフトウエアテストの分野の第一人者として有名。世界の主要企業のコンサルタントとしての豊富な実績を持つ。主な著書には，本書の姉妹書として有名な“Software System Testing and Quality Assurance”“Black-Box Testing”などがある。

ソフトウェア書籍次のページ　　　　ソフトウェア書籍目次　　　　　トップページ