
190
11
章 インフラストラクチャの変更のテスト
11.1
テストに対するアジャイルのアプローチ
多くの会社は、実装とテストをプロジェクトの別の段階に分離し、通常は別のチームが実施するよう
なプロセスを採用している。それに対し、アジャイルプロセスは、フィードバックループを短くするた
めに、テストと実装を統合することを奨励している(図 11-1)。テストは、変更が加えられるたびに継
続的に行われる。テスターとデベロッパが密接に協力し合い、自動テストを使って継続的なテストを実
現するのである。
フィックス
テスト テスト
変更
図 11-1 変更−テスト−フィックスのフィードバックループ
そのため、テストの自動化の目標としてもっとも効果的なのは、プロジェクトのテスト段階を短縮化
することではなく、コアワークフローにテストとフィックスを組み込むことである。アプリケーション
コードであれ、インフラストラクチャ定義であれ、システムに変更を加えるために仕事をしている人
は、継続的にテストを行う。変更が期待通りに動作することを確かめるためにテストを行い、変更がシ
ステムのほかの部分を壊さないことを確かめるためにテストを行う。そして、問題をのちのちまで引き
ずることになるやり残しの仕事がないことを確かめるためにテストを行う。
人々がテストをするのは、個々の問題を見つけ次第、システム変更の作業をまだ行っている間に修
正できるようにするためだ。彼らの頭のなかには、すべてがまだ新鮮な状態で残っている。変更の範
囲が非常に狭いため、