Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

212

11

章 インフラストラクチャの変更のテスト

してはならない。

永続的なテスト環境は、時間とともに変化し、本番システムとの統一性が保たれない場合がある。

イ ミ ュ ー タ ブ ル サ ー バ ー （「 8.4　イミュータブルサーバーのパターンとプラクティス」参照）を使えば、

テストを実行するたびにクリーンで統一されたテスト環境が作られることが保証される。

11.5

　

テストのロールとワークフロー

インフラチームは、テストを難しいものと考える傾向がある。システム管理者の典型的な品質保証プ

ロセスは、次のようなものだ。

1. 変更を加える。

2. 思いついたテストを適宜行う（時間があれば）。

3. その後しばらくの間、変更箇所に注意する。

裏を返せば、インフラストラクチャをよく理解しているテスターはあまりいない。そのため、ほとん

どのインフラストラクチャのテストは、うわべだけのものになりがちだ。

アジャイルソフトウェア開発の大きな成果のひとつは、デベロッパとテスターの縄張りを破ったこと

だ。品質保証を別のチームの職務とするのではなく、デベロッパとテスターが責任を共有するのであ

る。アジャイルチームは、システムがほぼ完成したときにテストのためにまとまった時間を割いたりせ

ず、コーディング開始と同時にテストも始める。

QAアナリストやテスターの役割については、アジャイルチームのなかでもまだ論争がある。私見で

は、うまく機能しているチームのなかでも、QAはデベロッパが作ったものに含まれている穴や漏れを

見つける価 ...