不同角色之間的劃分往往有助于在角色的沖突中將問題暴露，實現透明，最終改進和保證質量。任何的軟件開發團隊都離不開兩個基本角色：開發與測試。 你可以沒有項目經理，可以沒有架構師，也可以沒有設計師；但是不能沒有開發，否則沒有人可以幫你實現產品；也不能沒有測試，否則沒有人可以決定你的產品是 否能夠交付。這就好像你往杯子里面倒水必須要用眼睛看著，沒有眼睛反饋的信息，你永遠不知道何時該停下來，也不知道停在那里；我們不希望水太少，更不希望 水溢出來。眼睛與手的反饋循環就是我們實現倒水這一動作高質量的必要系統，而開發和測試的有效循環就是我們實現高質量軟件的必須環節。
但是開發和測試本身的角色的局限性造成了他們往往沒有辦法有效地形成循環，比如我們經常會聽到這樣的抱怨：
測試：這個軟件需要的環境太復雜，沒有辦法為每種情況都創建測試環境.
測試：我沒有辦法保證測試的一致性，因為環境在不停地變化，恢復到原來的狀態很麻煩.
開發：你是怎么測出這個Bug的，我怎么沒法重現？測試：我忘記步驟了.
其實這些問題都和測試人員本身的定位有關系，測試人員的首要目標是發現軟件中的問題，要做到這一點他們往往專注于軟件的反應而忽視了造成這種響應的原因，如：硬件軟件環境，系統配置情況，操作一致性等等；測試用例失敗有幾種原因：
功能缺陷BUG；
測試用例本身寫的有問題（ST或者ET腳本問題）；
測試環境有問題；
而這些正是開發人員修復Bug最需要的內容。但是測試人員不關心，或者沒有更多的精力來關心這些內容，造成了非常多的“不可重現”的Bug的出現。
我們可以通過持續集成以及對代碼進行版本管理控制來定位變更和導致功能缺陷的原因，同樣的，我們也可以對測試環境的變更進行控制和版本管理。之前提到過持續集成要求對一切進行版本管理，其中也包括測試環境。
初看上去，測試環境的管理是一個非常復雜的問題，之前是否遇到過下面一類問題？
“要測一個什么東西，需要什么軟件，然后手動安裝一遍，結果發現另外一個機器上其實已經有這個軟件了。” ——測試環境的復用和共享問題。
“有一個測試用例失敗了，可是之前測試的時候一直通過的，開發人員在開發環境下測試也沒有問題，測試人員費了九牛二虎之力，借助開發人員的調試幫助，結 果發現是測試環境中的一個配置參數改變了。 此時，另外一個測試人員冒了一句，我之前測試另外一個問題的時候將這個參數改掉了。” ——測試人員花了大量時間確定環境變更，測試環境的變更控制問題。
“有一個機器，你也在里面裝個東西，我也在里面裝個東西，結果這個機 器的環境越來越亂，桌面上亂起八糟，最后誰也不記得機器里面的一些文件有什么用處了，當初是因為什么原因使用的，又不敢刪除，怕其他人有用，可是又不知道 會是誰。” 測試環境的管理和記錄問題，好一些的會漸漸使用一些文檔進行記錄并共享，但是還是經常出現問題，畢竟文檔也會過期。
“一個測試MM突然大喊， 誰把我的模板和數據刪除啦，給我出來！！！ 四周鴉雀無聲。我小聲的問一句，你上傳到svn上了嗎，上次不是說過一切都要版本控制嗎？” 測試環境和數據的備份和刪除，廣義上說這個也屬于變更。
“我這里需要再安裝針對ubuntu和suse操作系統的測試，并且需要32位和64位都有，而且還要設置一大堆配置。可是現有的5臺機器都安裝滿了， 總不能重裝來重裝去的吧，每次重裝都要了我的老命了...” 測試硬件資源的利用，和環境管理的效率問題。自動配置技術和利用虛擬化技術解決，測試環境數據化，配置化，然后才能版本控制和管理。
開發人員：“我在自己機器上測試了沒問題啊”， 測試人員：“可我在測試環境下面就是有問題啊。” 統一的測試環境問題。
以上的這些問題，都指向了一個關鍵點，測試環境的管理，分而細之，又包括幾個重要的因素：變更、自動化、數據化、虛擬化、共享。
虛擬化技術
虛擬化技術可以幫助將測試環境數據化，自動化，并借此達到重復利用的目的。虛擬化技術有很多，比較優秀的有VMWare和Virtual Box。比如，很多測試環境是寄生在操作系統中的，我們可以將這些操作系統做成操作系統基線，平時不需要測試時可以不開著，要用的時候再開。這些操作系統基線可以進行版本控制，因為文件比較大，用svn之類的管理可能會遇到一些問題，可以針對性設計一些大文件版本控制軟件（比如：結合SVN和FTP的優點）。
配置管理自動化
先后研究了幾種配置管理的工具，Chef， CfEngine， puppet，最后用的比較多的是Chef。Chef比較好的一點是提供OpenSouce Chef Server，可以自己搭建服務器，也是這幾個里面最先搭成功的，算是比較容易上手吧。就像一個大廚（Chef）使用刀（Knife）實驗各種不同的菜單 （Recipes），制成各種食譜（CookBook）一樣，一個配置管理工程師就是用它來制作不同的測試環境。