1.1 イントロダクション
1.2 テスティングとテスト自動化の違い
1.2.1 テスティング
1.2.2 テスト自動化
1.3 Vモデル
1.4開発ライフサイクル全体のテスティング活動を助けるツール
1.5 テスト自動化の利点
1.6 テスト自動化に共通する問題
1.7 テスティング活動
1.7.1 テスト条件の識別
1.7.2 テストケースの設計
1.7.3 テストケースの実装
1.7.4 テストケースの実行
1.7.5 テスト結果と期待結果の比較
1.8 テスト設計は自動化の対象か？
1.8.1 自動化しやすい活動
1.8.2 テストケース設計の自動化
1.8.2.1 コードベースのテスト入力生成
1.8.2.2 インターフェースベースのテスト生成
1.8.2.3 仕様ベースのテスト生成
1.8.2.4 テスト設計の自動化のまとめ
1.9 ソフトウェアテスティング自動化の限界
1.9.1 手動テスティングはなくならない
1.9.2 手動テストの方が自動テストよりも多くの欠陥が見つかる
1.9.3 テスト品質へのさらなる依存
1.9.4 テスト自動化をしてもテストが効果的になるわけではない
1.9.5 テスト自動化がソフトウェア開発を妨げてしまう可能性
1.9.6 ツールは想像力ゼロである
1.10 まとめ
2.1 例題のアプリケーション「Scribble」
2.1.1 例題のテストケース─Scribbleのリスト編集
2.1.2 Scribbleのリスト編集機能のテスト
2.1.3 テストで入力されたのは何か？
2.2 手動テストのプロセス─何を自動化すべきか？
2.2.1 アドホックテスト（テストスクリプトなし）
2.2.2 曖昧な手動テストスクリプト
2.2.3 詳細な手動テストスクリプト
2.3 テスト実行の自動化─入力
2.3.1 テスト入力の自動化
2.3.2 記録したテストスクリプトの再生
2.3.3 自動テストスクリプトは手動テストスクリプトとは別物
2.3.4 テスト入力だけの自動化のメリットと用途
2.3.5 手動テストの記録の短所
2.3.6 提案「単なる記録によるテスティングの自動化は行うなかれ」
2.3.7 自動実行＋手動検証？
2.4 テスト結果の比較の自動化
2.4.1 テストケースの結果の比較を決定するとき
2.4.2 どれだけ比較すべきか？
2.4.3 動的比較
2.4.4 実行後比較
2.4.5 比較を自動化しても比較結果のメッセージは手動でチェックしなくてはならない
2.4.6 比較の自動化は些細なことではない
2.4.6.1 決定すべき選択が多岐にわたる
2.4.6.2 テストスクリプトはすぐに非常に複雑になる
2.4.6.3 必要な作業がたくさんある
2.5 テスト自動化の進化における次のステップ
2.5.1 テストが2回目に失敗する理由（環境面でつまずく）
2.5.2 検証に関するその他の（よく見落とされる）要件
2.5.3 ファイルまたはデータベースの変更を検証する方法
2.5.4 全てのファイルをどこに置く？
2.6 結論─自動化は自動的には行われない
2.7 まとめ
3.1 イントロダクション
3.1.1 プログラミングとの類似性
3.1.2 スクリプティングの一般的な課題
3.1.2.1 テストスクリプトは何のために使われるのか
3.1.2.2 良いスクリプトと悪いスクリプト
3.1.2.3 良いテストの原則
3.1.2.4 「読みやすい」スクリプト？
3.1.2.5 自分でドキュメント化するスクリプト？
3.1.3 テストケースの設計と実装
3.1.3.1 テストケースの設計
3.1.3.2 テストケースの実装
3.1.4 スクリプトドキュメンテーションの勧め
3.2 スクリプティングの技法
3.2.1 リニアスクリプト
3.2.1.1 リニアスクリプトの長所
3.2.1.2 いつリニアスクリプトを使うか
3.2.1.3 リニアスクリプトの短所
3.2.2 構造化スクリプティング
3.2.3 共有スクリプト
3.2.3.1 リニアスクリプトから共有スクリプトへの例
3.2.3.2 共有スクリプトの種類
3.2.3.3 共有スクリプトの長所と短所
3.2.3.4 共有スクリプトを最大限生かすには
3.2.4 データ駆動スクリプト
3.2.4.1 データ駆動の例1:
同じスクリプトに違うデータを使う
3.2.4.2 データ駆動の例2:
より洗練されたデータ駆動スクリプト
3.2.4.3 なぜこんなに複雑になってしまうのか
3.2.4.4 データ駆動スクリプトの長所
3.2.4.5 データ駆動スクリプトの短所
3.2.5 キーワード駆動スクリプト
3.2.5.1 アプリケーションについての知識を織り込むキーワード駆動スクリプト
3.2.5.2 キーワード駆動スクリプトの長所
3.2.5.3 キーワード駆動スクリプトの実装
3.3 スクリプト前処理
3.3.1 スクリプト前処理の機能
3.3.1.1 整形処理
3.3.1.2 静的解析
3.3.1.3 一般的な置換
3.3.1.4 テスト固有の置換
3.3.1.5 置換を行う際に注意すべきこと
3.3.1.6 前処理の実装
3.4 まとめ
4.1 検証、比較、そして自動化
4.1.1 比較による検証
4.1.2 計画された比較とアドホックな比較
4.1.3 結果の予想と実行結果の検証
4.1.4 なぜ比較を自動化するのか
4.1.5 何を比較するべきなのか
4.1.6 自動比較の限界
4.2 比較ツールは何を比較するか？
4.2.1 何が比較できるか
4.2.2 比較で何が分かるか
4.2.3 比較では分からないものは何か
4.3 動的比較
4.3.1 動的比較とは
4.3.2 ツールのサポートと実装
4.3.3 テストケースへの工夫
4.3.4 複雑さとメンテナンスコストの上昇
4.4 実行後比較
4.4.1 実行後比較とは
4.4.2 ツールのサポート
4.4.3 比較の順番と構造
4.4.4 能動的および受動的実行後比較
4.4.5 実行後比較の実装
4.4.5.1 テスト実行と実行後比較の結合
4.4.5.2 テスト実行と実行後比較の結合の4つの方法
4.5 単純な比較
4.6 複雑な比較
4.6.1 なぜ複雑な比較が必要になるか
4.6.2 単純なマスキング
4.6.3 マスキングのための検索技法
4.6.4 正規表現を使った検索
4.6.5 複雑な比較の実装
4.7 テストの感度
4.7.1 センシティブなテストとロバストなテスト
4.7.2 センシティブなテストとロバストなテストのトレードオフ
4.7.3 冗長性
4.7.4 テスト感度の戦略
4.8 異なるタイプの比較結果
4.8.1 ディスクベースの比較結果
4.8.1.1 テキストファイルの比較
4.8.1.2 テキスト形式ではないデータの比較
4.8.1.3 データベースやバイナリファイルの比較
4.8.2 画面ベースの比較結果
4.8.2.1 キャラクタベースのアプリケーション
4.8.2.2 GUIアプリケーション
4.8.2.3 画像イメージ
4.8.3 その他のタイプの比較結果
4.8.3.1 マルチメディアアプリケーション
4.8.3.2 通信アプリケーション
4.9 比較フィルタ
4.9.1 自前の実行後比較ツールを作るための実践的なアプローチ：比較プロセス
4.9.2 フィルタとは？
4.9.3 比較プロセスの実装
4.9.4 フィルタの長所と短所
4.9.5 フィルタの例
4.9.6 フィルタの直列接続
4.9.7 比較の標準化
4.9.8 期待結果の生成
4.10 比較のガイドライン
4.10.1 シンプルにする
4.10.2 ドキュメントに残す
4.10.3 できるだけ標準化する
4.10.4 分割統治
4.10.5 効率性を心がける
4.10.6 ビットマップの比較を避ける
4.10.7 センシティブなテストとロバストなテストのバランスを取る
4.11 まとめ
5.1 テストウェアアーキテクチャとは何か
5.1.1 用語
5.2 カギとなる4つの課題
5.2.1 規模
5.2.2 再利用性
5.2.3 複数のバージョン
5.2.4 プラットフォームと環境からの独立
5.3 取り組み方
5.3.1 序文
5.3.2 基本概念
5.3.2.1 テストセット
5.3.2.2 テストスイート
5.3.2.3 基本概念の限界
5.3.3 テストウェアセット
5.3.3.1 テストセット
5.3.3.2 スクリプトセット
5.3.3.3 データセット
5.3.3.4 ユーティリティセット
5.3.4 テストスイート
5.3.5 テストウェアライブラリ
5.3.5.1 テストウェアライブラリ、テストスイート、テストセットの例
5.3.5.2 テストウェアライブラリへのアクセス
5.3.5.3 構成管理
5.3.5.4 テストウェアの更新の制御
5.3.6 テスト結果
5.3.6.1 テストの成果物と二次成果物
5.3.6.2 テスト結果は保存すべきか？
5.3.6.3 論理的構造
5.3.7 物理的構造
5.3.7.1 テストウェアセットディレクトリ
5.3.7.2 テストスイート
5.3.7.3 テスト結果
5.3.7.4 命名規約
5.3.7.5 プラットフォームと環境への依存性
5.3.7.6 拡張性
5.3.7.7 テストケースの定義とトレーサビリティ
5.3.8 テストツールとのインターフェース
5.4 これはやりすぎだろうか？
5.5 まとめ
6.1 前処理と後処理とは何か？
6.1.1 前処理
6.1.2 後処理
6.1.3 なぜこれらの用語を使うのか？
6.1.4 なぜ前処理と後処理を自動化するのか？
6.1.5 常にセットアップするか、保存・復元か？
6.2 前処理のタスク
6.2.1 前処理のタスク
6.2.2 後処理のタスク
6.2.3 異なるステージでの前処理と後処理
6.3 テストケース実行後に何が起こるか？
6.3.1 正常終了の後
6.3.2 異常終了の後
6.4 実装の問題
6.4.1 テストケースの例
6.4.2 スクリプト
6.4.3 コマンドファイルの使用
6.4.4 データ駆動アプローチ
6.4.5 キーワード駆動アプローチ
6.4.6 テストケース定義ファイルの使用
6.5 まとめ
7.1 自動テストのメンテナンスにおける問題
7.2 テストメンテナンスの要素
7.2.1 テストケースの数
7.2.2 テストデータの量
7.2.3 テストデータの形式
7.2.4 テストケースの実行時間
7.2.5 テストケースのデバッグ能力
7.2.6 テストの相互依存性
7.2.7 命名規則
7.2.8 テストの複雑性
7.2.9 テストドキュメンテーション
7.2.10 その他の要素
7.3 落とし穴
7.3.1 間違ったことをするようにツールが仕向けている
7.3.2 容易なアプローチが高いメンテナンスコストをもたらす
7.3.3 最初の熱意
7.3.4 投資利益率
7.4 戦略と戦術
7.4.1 戦略
7.4.2 戦術
7.5 まとめ
8.1 なぜテスティングとテスト自動化を計測するのか？
8.1.1 投資利益率（ROI）
8.1.1.1 テスティングの改善のROI
8.1.1.2 テスト自動化のROI
8.1.2 選択肢を評価し、代替案を比較して、改善効果をモニタする
8.1.3 問題の早期発見と予測
8.1.4 標準や競合に対するベンチマーク
8.2 計測できるもの
8.2.1 Gilbの法則
8.2.2 計測可能なものの例
8.2.3 役に立つ計測指標
8.3 テスティングとテスト自動化の目的
8.3.1 テスティングの目的
8.3.2 テスト自動化の目的
8.3.3 達成可能な目的
8.4 ソフトウェアテストの属性
8.4.1 テストの有効性の計測
8.4.1.1 欠陥検出率（DDP）
8.4.1.2 欠陥修正率（DFP）
8.4.1.3 信用度に関するテストの有効性の計測指標
8.4.2 テストの徹底性の計測
8.4.2.1 欠陥を見つけなかったテストの価値
8.4.2.2 徹底性の主観評価
8.4.2.3 徹底性の客観的な評価：テストカバレッジの測定
8.5 テスト自動化の属性
8.5.1 保守性
8.5.2 効率性
8.5.3 信頼性
8.5.4 柔軟性
8.5.5 ユーザビリティ
8.5.6 堅牢性
8.5.7 移植性
8.6 最高のテスト自動化の枠組みはどれだろう？
8.7 本当に全てを計測すべきなのか？
8.8 まとめ
9.1 どのテストを（最初に）自動化すべきか？
9.1.1 それは価値があるの？
9.1.2 テストの種類
9.1.2.1 機能テスト
9.1.2.2 性能テスト
9.1.2.3 非機能品質
9.1.3 最初に何を自動化する？
9.1.4 自動化の時期と程度
9.1.5 「手っ取り早い成果」を目指す
9.2 どのテストをいつ実行するか
9.2.1 テストのサブセットをどのように選択するか?
9.2.2 「テストセレクタ」の実装
9.3 テスト実行の順序
9.3.1 テスト分析の負荷
9.3.2 分析時間最小化のための論理的な階層付け
9.3.3 テスト実行時のその他の要件
9.3.4 テストの分散
9.4 テストステータス
9.4.1 成功か失敗か
9.4.2 ツールは成功と失敗を判定できない
9.4.3 既知の未修正欠陥
9.4.4 現実的な解決策
9.4.4.1 以前失敗したテストを全て無視する？
9.4.4.2 失敗した結果をOKとしてしまう？
9.4.5 テストステータス：期待された失敗
9.4.5.1 もう1つの期待結果
9.4.6 テストステータス：不明
9.4.6.1 欠陥が修正された場合
9.4.6.2 欠陥は修正されていないがそれ以外の箇所が変更された場合
9.4.6.3 期待結果が消失している
9.4.6.4 テストステータスを「成功」に復元する
9.4.7 テストステータスのサマリ
9.4.8 欠陥ステータスのさらなる詳細
9.5 （自動）テストの容易性を高めるためのソフトウェア設計
9.6 同期
9.7 自動テストの進捗のモニタリング
9.8 ツールに合わせた枠組みのテーラリング
9.9 まとめ
10.1 第10章と第11章の概要
10.1.1 ツールの選択と導入のプロセス
10.1.2 ツールの選択プロセスのアプローチ
10.2 ツール選択をどのように開始するか
10.3 ツール選択プロジェクト
10.3.1 重要性と優先順位
10.4 ツール選択チーム
10.4.1 ツール選択チームのリーダー
10.4.2 ツール選択チームのメンバー
10.5 要件の把握
10.5.1 解決すべき問題は何か？
10.5.2 別の解決策を探る
10.5.2.1 手動テストの問題
10.5.2.2 回帰テストを行う時間がない
10.5.2.3 テストデータやテストのセットアップ
10.5.2.4 テストドキュメントが十分でない
10.5.2.5 ソフトウェアがどれくらいテストされているか分からない
10.5.2.6 効果のないテスト
10.5.3 ツール選択のタイミング
10.5.4 テストツールはどれだけ役立つか？
10.5.5 テストツール導入の価値は？
10.6 制約条件の把握
10.6.1 環境の制約
10.6.2 テスト対象のソフトウェアとの共存
10.6.3 サプライヤーの制約
10.6.4 コストの制約
10.6.5 政治的な制約
10.6.6 品質の制約
10.7 ツールを自作するか？
購入するか？
10.8 市場で入手可能なツールの把握
10.8.1 機能の評価
10.8.1.1 カテゴリ「必須」
10.8.1.2 カテゴリ「あると望ましい」
10.8.1.3 カテゴリ「考慮不要」
10.8.1.4 機能が別のカテゴリに変わる
10.8.1.5 機能のタイプ
10.8.2 ツールの候補リストの作成
10.8.3 不適格なツールの除外
10.9 候補リストに残ったツールの評価
10.9.1 機能の比較
10.9.1.1 その時点のツールに関する情報の収集
10.9.1.2 ツール評価レポートの調査
10.9.1.3 ツールを実際に使用している現場へのコンタクト
10.9.2 自社内でのデモンストレーション
10.9.2.1 ベンダーによるデモの前に準備すること
10.9.2.2 デモンストレーション当日に追加するテスト
10.9.2.3 デモンストレーション当日に行うこと
10.9.2.4 デモンストレーション後に行うこと
10.9.3 スクリプトメンテナンスのテスト
10.9.4 選考トライアルの実施
10.10 意思決定を行う
10.10.1 投資効果検討書を評価する
10.10.2 評価を止めるタイミング
10.10.3 評価と選択のプロセスの完了
10.11 まとめ
11.1 何が間違いだったのか？
11.2 導入プロセスの管理の重要性
11.2.1 ツールはシェルフウェアになりがち
11.2.2 ツールの導入プロセス
11.2.3
変革の管理
11.3 導入と変革のプロセスにおける役割
11.3.1 ツールの「推進役」
11.3.2 変革の請負人
11.3.3 組織上層部の支援者
11.3.4 ツール管理人
11.3.5 導入チーム
11.3.5.1 情報の収集
11.3.5.2 情報伝達と支援
11.4 組織幹部のコミットメント
11.4.1 成功するために重要なこと
11.4.2 現実的な期待
11.5 自動化導入の準備
11.5.1 広報活動
11.5.2 最初の関心の喚起
11.5.3 継続的な広報活動
11.5.4 デモンストレーションのテスト
11.5.5 評価ライセンスを利用しての適合性評価
11.5.6 組織内の市場調査
11.6 パイロットプロジェクト
11.6.1 なぜ、パイロットプロジェクトが必要なのか
11.6.2 テスティングプロセスの変化の見極め
11.6.3 自動化の枠組みの構築と試用
11.6.4 パイロットプロジェクトの結果の評価
11.7 計画性を持ったツールの段階的導入や本格展開
11.7.1 計画の重要性
11.7.2 ツール利用のためのトレーニングの準備
11.7.3 テスト自動化の効果の監視
11.8 テスティングツール導入に特有の問題
11.8.1 他のツールやシステムとのインターフェース
11.8.2 ツールの習得に要する時間と労力
11.8.3 メンテナンス環境
11.9 人の問題
11.9.1 人の問題を管理しないことの危険性
11.9.2 変化の方程式
11.9.3 仕事のやり方を変えるように人々を説得する
11.9.4 変化の成功は将来の変化を育てる
11.9.5 変化を受け入れる人々の性質の分類
11.10 結論
11.10.1 ツール導入の「氷山」
11.10.2 ツール導入の評価
11.10.3 いつ終わるのか？
11.11 まとめ
12.1 Seleniumとは
12.1.1 Selenium IDE
12.1.2 Selenium WebDriver
12.2 テストスクリプトの保守性を高める
12.2.1 スクリプト共通化の問題
12.2.2 UIマッピング
12.2.3 ページオブジェクトデザインパターン
12.2.4 ページオブジェクトクラス実装のポイント
12.2.4.1 ページオブジェクトクラスには結果比較のロジックを含めない
12.2.4.2 ページ遷移を伴うメソッドは、他のページオブジェクトクラスのインスタンスを生成して返す
12.2.4.3 コンストラクタで現在のページが期待したものかをチェックする
12.2.5 ページオブジェクトをデータ駆動テストで利用する
12.3 まとめ
13.1 第1部の振り返り
13.1.1 データ駆動スクリプト
13.1.2 キーワード駆動スクリプト
13.2 運用上の課題
13.2.1 データ駆動スクリプトを運用に乗せる際の課題
13.2.2 キーワード駆動スクリプトを運用に乗せる際の課題
13.3 証券系システムのシナリオテストにおけるキーワード駆動スクリプトの利用例
13.3.1 自動化ツール
13.3.2 アーキテクチャ
13.3.2.1 制御エンジン
13.3.2.2 結果出力エンジン
13.3.2.3 オブジェクトマッピング
13.3.2.4 キーワードライブラリ
13.3.2.5 テストデータ
13.3.2.6 テストスクリプト
13.3.3 工夫点
13.3.3.1 キーワードの粒度設定
13.3.3.2 コードの半自動生成
13.4 まとめ
14.1 テストウェアアーキテクチャの統合と管理
14.1.1 ビルドプロセス
14.1.2 バージョン管理システムの利用
14.2 テスト実行環境の再現性を保つ
14.2.1 データベース
14.2.2 仮想マシンイメージ
14.2.3 サーバー構成管理ツール
14.2.4 Immutable
Infrastructure
14.3 CI（継続的インテグレーション）
14.3.1 CIとは
14.3.2 ビルドパイプライン
14.3.3 メトリクス
14.4 Travis CI
14.4.1 Travis CIの特徴
14.4.2 .travis.yml
14.4.3 ビルドライフサイクル
14.4.4 外部SaaSとの連携
15.1 システムテスト設計における問題と自動化
15.2 状態遷移に着目したテストケースの生成・選択
15.2.1 状態間の全てのパスを網羅する
15.2.2 特定のパスを重点的に網羅する
15.2.3 全ての状態を通る
15.2.4 許容されないパスを通る（異常系への対応）
15.3 テスティングフレームワークの作成
15.3.1 JUnit4
15.3.1.1 テストメソッドの実行順序
15.3.1.2 JUnit4のコア
15.3.2 JGraphT
15.3.2.1 グラフの基礎知識
15.3.2.2 JGraphTを使うメリット
15.3.3 状態と動作をフレームワークとして定義する
15.3.4 網羅方法を指定できるようにする
15.3.5 Gitからモジュールの変更を検知して重み付けに活かす
15.3.6 Webブラウザを使うテストと連携する
15.4 まとめ