1章　テストとは？ テストマネージャとは？

• 1-1　テストって何？
• 1-2　ソフトウェアほにゃらら管理

2章　テストのプランニング

• 2-1　プランニングの範囲
• 2-2　プランニングの流れ
• 2-3　マスターテストプラン作成のその前に
  • 2-3-1　テストする範囲を決める
  • 2-3-2　テスト環境を決める
  • 2-3-3　テストのやり方を決める
  • 2-3-4　見積もりとメンバーの人選
• 2-4　テストプランの作成
  • 2-4-1　文章番号
  • 2-4-2　レファレンス
  • 2-4-3　はじめに
  • 2-4-4　テストアイテム（Test Items）
  • 2-4-5　テストする機能（Features to Be Tested）
  • 2-4-6　テストする必要のない機能（Features Not to Be Tested）
  • 2-4-7　アプローチ（Approach）
  • 2-4-8　テストアイテムの合否判定基準（Item pass/fail criteria）
  • 2-4-9　中止基準と再開要件（Suspension criteria and resumption requirements）
  • 2-4-10　テスト成果物（Test deliverables）
  • 2-4-11　テスティングタスク（Testing tasks）
  • 2-4-12　実行環境（Environmental needs）
  • 2-4-13　責任範囲（Responsibilities）
  • 2-4-14　スケジュール（Schedule）
  • 2-4-15　人員計画，トレーニングプラン（Staffing and training needs）
  • 2-4-16　リスクと対策（Risks and contingencies）
  • 2-4-17　承認（Approvals）
• 2-5　まとめ
  • コラム　メトリクスを決めるには

3章　テスト対象の分析とテスト設計

• 3-1　テスト対象の分析・設計を行う
  • 3-1-1　テスト対象の情報収集
  • 3-1-2　テスト対象の要求（仕様）を整理し，一覧にする
  • 3-1-3　テスト対象の要求に適用するテストの種類を具体的にする
  • 3-1-4　優先度が高いものを洗い出す
• 3-2　テストケース作成方針を決める
  • 3-2-1　どのテストベースを使ってテストケースを作成するか
  • 3-2-2　どのようにテストケースを管理するか
  • 3-2-3　テスト仕様書の構成
  • 3-2-4　テストケースの詳細度と粒度を決める
  • 3-2-5　テストパスの種類
• 3-3　その他にしておくこと
  • 3-3-1　テスト対象の分析・設計時の不明点を確認する
  • 3-3-2　ヒアリング結果をもとにドキュメントを起こす
• 3-4　まとめ
  • コラム　休暇

4章　テストケースの管理

• 4-1　なぜテストケースの管理が大切なのか？
• 4-2　テストケースの書き方
  • 4-2-1　機能テスト
  • 4-2-2　ドメインテスト
  • 4-2-3　スペックベーステスト（Specification-based testing）
  • 4-2-4　ストレステスト
  • 4-2-5　回帰テスト
  • 4-2-6　ユーザテスト
  • 4-2-7　シナリオテスト
  • 4-2-8　状態遷移テスト
  • 4-2-9　自動化によるボリュームテスト
• 4-3　テストタスクのスケジューリング
• 4-4　良いテストケースの作成
• 4-5　効率的なテストケースとは？
• 4-6　テストケースの管理
  • 4-6-1　テストケース数の管理
  • 4-6-2　ツールによる管理
• 4-7　テストケースの実行
• 4-8　まとめ
  • コラム　スキルのある開発者とそうでない開発者

5章　要求ベースのテスト

• 5-1　ソフトウェア要求ってちゃんとわかっています？
• 5-2　テスト可能な要求
  • 5-2-1　テスト可能な要求の書き方（具象化）
  • 5-2-2　要求の網羅（要求のテスト）
• 5-3　非機能要求のテスト
  • 5-3-1　外部インタフェース
  • 5-3-2　制約
  • 5-3-3　品質特性（ISO9126）
• 5-4　システムテストと非機能要求のテスト
• 5-5　パフォーマンステスト（効率性−時間効率性）
• 5-6　要求に対するテストのタイミング
• 5-7　まとめ
  • コラム　「要件」と「要求」の狭間で

6章　バグの管理（障害管理）

• 6-1　バグを見つけたら報告せよ
  • 6-1-1　実際のバグの報告の仕方
  • 6-1-2　バグレポートで収集すべき情報
  • 6-1-3　バグの重要度
  • 6-1-4　バグの修正分類
• 6-2　バグの一生を追う（バグのライフサイクル）
  • 6-2-1　バグの状態
  • 6-2-2　状態ごとの責任の所在
• 6-3　見つけたバグはとことん使い回すべし（バグの分析）
  • 6-3-1　バグの除去が確実に行われているかを知る情報源
  • 6-3-2　納品のための品質を測定するための情報源
  • 6-3-3　長期的なバグの予防につなげるための情報源
  • 6-3-4　テストケースのための情報源
• 6-4　バグ管理ツール
  • 6-4-1　入手可能なツール
• 6-5　よく問題になる落とし穴
  • 6-5-1　バグの粒度（1つのバグとして入れるか，多数のバグとして入れるか）
  • 6-5-2　どうしても再現できないとき
  • 6-5-3　バグ管理ツールを使わせるコツ
• 6-6　まとめ
  • コラム　バグと障害と欠陥と不具合の違いとは？

7章　本当の品質とは（品質管理）

• 7-1　品質の属性のトレードオフ
• 7-2　スペースシャトルのソフトウェアと年賀状ソフトウェアは同じ品質？（製品による品質ターゲットの違い）
  • 7-2-1　信頼性の尺度
• 7-3　Good Enough Qualityソフトウェア（てーげーソフトウェア）
• 7-4　まとめ

8章　品質の足腰（構成管理，統合，ビルド）

• 8-1　はじめに
• 8-2　構成管理テスト
  • 8-2-1　その他注意する点
• 8-3　統合テスト
  • 8-3-1　増加テスト(トップダウンテスト，ボトムアップテスト)
  • 8-3-2　非増加テスト（ビックバンテスト）
• 8-4　デイリービルド＆スモークテスト
• 8-5　まとめ

9章　リスク管理

• 9-1　リスクの基本
• 9-2　デンバー空港の例
• 9-3　製品品質に関するリスク
  • 9-3-1　品質が単に悪い（バグが収束しないなど）
  • 9-3-2　あるコンポーネントの品質が非常に低い
  • 9-3-3　ミッションクリティカルの製品のテスト
  • 9-3-4　手戻り工数が高い
  • 9-3-5　上位依存性
  • 9-3-6　ソフトウェア以外の依存
  • 9-3-7　新規に使うテクノロジや言語
  • 9-3-8　複雑性の高いコードが多い（McCabeの複雑度）
  • 9-3-9　外から購入したモジュールを使っている
  • 9-3-10　リスクの評価および計算
• 9-4　テストチーム運営に関するリスク
  • 9-4-1　時間と予算の欠如
  • 9-4-2　テスト担当者のスキル不足
• 9-5　大規模プロジェクトでのリスク
• 9-6　まとめ

10章　テストチームの運営

• 10-1　はじめに
• 10-2　テストチームを作る
  • 10-2-1　開発者の数
  • 10-2-2　開発規模，開発期間
  • 10-2-3　目標の製品品質
  • 10-2-4　テスト担当者の質
• 10-3　テストのお財布（テストのコスト）
  • 10-3-1　見積もれない品質コスト
  • 10-3-2　でも見積もってみよう品質コスト
• 10-4　品質のコストの減らし方（品質を保ちつつコストを減らす）
• 10-5　採用
  • 10-5-1　テスト担当者の本質的なスキルセット
  • 10-5-2　面接での注意点
  • 10-5-3　時間配分
  • 10-5-4　圧迫面接
  • 10-5-5　履歴書（職務経歴書）を信じるな
  • 10-5-6　最終判断
  • コラム　世界最強のMicrosoftの面接
• 10-6　モチベーション（金か名誉か？）
  • 10-6-1　報奨
  • 10-6-2　ゴールとキャリアプランの設定を定期的に行う
  • 10-6-3　適正給与の支払い
• 10-7　皆仲良く
  • 10-7-1　開発者とのコミュニケーション
• 10-8　アウトソーシング
• 10-9　まとめ