ソフトウェアテスト293の鉄則
「ソフトウェアテスト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.テスト計画を共有する
章末付録２ 「良いテスト計画」の構成要素
用語と概念
テスト計画の役割
テスト計画の品質基準
テスト計画の経験則
付録 ソフトウェアテストに対するコンテキスト駆動型アプローチ
参考文献
訳者あとがき
索引