目次
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 まとめ