
インフラストラクチャの変更のテスト
189
11
章
イ ン フ ラ スト ラ ク チ ャ の 変 更 の テ スト
前章では、Infrastructure as CodeにCIやCDといったソフトウェア開発のプラクティスを応用する
方法を説明した。前章の大きなテーマは、品質の確保だった。この章では、テスト、特に自動テストの
詳細を掘り下げていく。自動テストは、システムに対する変更を継続的にテストするための基本だ。し
かし、多くのチームは、自動テストの構築とメンテナンスを持続していくことに苦労している。この章
では、自動テストの体制を確立、維持できているチームのアプローチを見ていく。
テストの目的は、仕事のスピードアップを助けることである。残念ながら、多くの会社では、テスト
は仕事を遅らせるものだと考えられている。品質とデリバリースピードは二者択一のトレードオフにな
る反対の力だという誤解が広く浸透している。このような発想からは、オートメーションによってシス
テムのテストに時間がかからなくなり、デリバリープロセスをスピードアップできるという考えになる。
テストはデリバリースピードの敵であり、オートメーションはテストを高速化する特効薬だという誤
解から抜け出せなければ、コストがかかった挙句、テストの自動化に失敗する羽目になるだろう。
本当は、システムの品質こそが小気味よいデリバリースピードを実現するのである。問題を見つけ
て修正することに時間をかけないと、できあがったシステムは脆弱になる。脆弱なシステムは変更し ...