『実践アジャイルテスト』第14章のコメント・疑問

第14章 アジャイルテストの自動化戦略(P271)

14.1 テスト自動化のためにアジャイルのアプローチ(P272)

14.1.1 自動化テストのカテゴリー(P272)

P.273 4行目 「オズの魔法使い型の活動」 P.136参照。コンピュータのように振る舞う人間の黒幕？ (Ｙｏｕ＆Ｉ)

14.1.1 テスト自動化のピラミッド(P274)

「テスト自動化」の観点では３つのレイヤに分類される。（岩井）

下層にいくほど自動化できる範囲が多く、ROIが大きい？（岩井）

→下層の方がテストの自動化が行い易いので、自動化に取り組む作業のROI効果が高い。と理解しました。 (Ｙｏｕ＆Ｉ)

P.276 「通常は前のプロジェクトから引き継がれたことによって逆さまになります」ピラミッド構造が逆になっている事の説明ですが、自動化されていないと下層のテスト項目数は少なめになる？ (Ｙｏｕ＆Ｉ)

14.2 何を自動化できるか？(P277)

14.2.1 継続的インテグレーション、ビルド、展開(P278)

14.2.2 単体テストとコンポーネントテスト(P280)

14.2.3 APIとウェブサービスのテスト(P280)

14.2.4 GUIの裏側のテスト(P280)

14.2.5 GUIのテスト(P280)

GUIのテスタビリティとは、オブジェクトの名前やIDが自動生成されたものでないかどうか。（岩井）

GUIのテストではビジネスの機能テストを行うべきではない。（岩井）

14.2.6 負荷テスト(P281)

14.2.7 比較(P281)

P.281の下の方。「データベースを比較するためのスクリプト」とは、テーブル内のデータをBefore/After比較するようなイメージでしょうか。あれば確かに便利そうです。（岩井）

14.2.8 繰り返し作業(P282)

テストだけでなくルーチンワーク的な管理作業も自動化しようということですね。（岩井）

14.2.9 データ生成や準備(P282)

リサの話は、独立したテスト用スキーマをいったんクリアして自動で生成できるスクリプトを用意しておくといいよ、という話？（岩井）

14.3 何を自動化すべきでないか？(P283)

自動化すると、メンテナンス性の問題やその部分がトラックナンバー１といった状況になりやすい気がします。自分が良く指摘されています。 (Ｙｏｕ＆Ｉ)

14.3.1 ユーザビリティテスト(P283)

14.3.2 探索的テスト(P284)

14.3.3 絶対に失敗しないテスト(P284)

14.3.4 一回限りのテスト(P285)

14.4 何が自動化しにくいのか？(P286)

14.5 自動化の戦略を立てる―どこから始めるべきか？(P287)

14.5.1 どこが最大の痛みか？(P287)

14.5.2 複数レイヤーによるアプローチ(P289)

14.5.3 テスト設計と保守を考慮する(P290)

14.5.4 正しいツールを選択する(P292)

14.6 テスト自動化にアジャイルの原則を適用する(P297)

14.6.1 シンプルに保つ(P297)

14.6.2 反復的なフィードバック(P298)

14.6.3 チーム全体のアプローチ(P299)

14.6.4 正しいことを行なうために時間を取る(P301)

14.6.5 実行により学習する(P303)

14.6.6 アジャイルのコーディング習慣をテストに適用する(P303)

14.7 テストのためにデータを提供する(P304)

14.7.1 データ生成ツール(P304)

14.7.2 データベースアクセスを回避する(P305)

14.7.3 いつデータベースアクセスが避けられなくなるのか/望ましいのか？(P307)

14.7.4 ニーズを理解する(P310)

14.8 自動化ツールを評価する(P311)

14.8.1 自動化ツールの要求を識別する(P311)

14.8.2 一度に1つのツール(P312)

14.8.3 ツールを選定する(P314)

14.8.4 アジャイルフレンドリーなツール(P316)

14.9 自動化を実現する(P316)

14.10 自動化されたテストを管理する(P319)

14.10.1 テストを構成する(P320)

14.10.2 テスト結果を整理する(P322)

14.11 始めましょう(P324)

14.12 まとめ(P325)