不同角色之间的划分往往有助于在角色的冲突中将问题暴露，实现透明，最终改进和保证质量。任何的软件开发团队都离不开两个基本角色：开发与测试。 你可以没有项目经理，可以没有架构师，也可以没有设计师；但是不能没有开发，否则没有人可以帮你实现产品；也不能没有测试，否则没有人可以决定你的产品是 否能够交付。这就好像你往杯子里面倒水必须要用眼睛看着，没有眼睛反馈的信息，你永远不知道何时该停下来，也不知道停在那里；我们不希望水太少，更不希望 水溢出来。眼睛与手的反馈循环就是我们实现倒水这一动作高质量的必要系统，而开发和测试的有效循环就是我们实现高质量软件的必须环节。
但是开发和测试本身的角色的局限性造成了他们往往没有办法有效地形成循环，比如我们经常会听到这样的抱怨：
测试：这个软件需要的环境太复杂，没有办法为每种情况都创建测试环境.
测试：我没有办法保证测试的一致性，因为环境在不停地变化，恢复到原来的状态很麻烦.
开发：你是怎么测出这个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）一样，一个配置管理工程师就是用它来制作不同的测试环境。