前段时间我们测试部开周例会的时候，功能组同事提到现在测试流程比较混乱。对于流程这块我们测试部以及其他领导聊了很多，从测试环境和开发环境的使用，再到开发人员提测项目方式以及项目变更控制流程，最后讨论到测试人员与产品人员以及开发人员在需求上的矛盾。这里的矛盾不是对待是什么需求的问题，当然是什么样需求、要实现什么样的产品是由产品部同事和市场部同事制确定的，开发部和测试部只有执行和建议的份。产品部是老大，一个IT产品公司中可以没有测试部，但是不能没有产品部，产品的创新、以及市场竞争力主要依靠产品部门，这里有些扯的远啦。当然测试部更重要，O(∩_∩)O哈哈~
开发人员也有独立的开发环境，但是他们却很少在他们的开发环境上使用，他们在自己的本地电脑上开发、修改bug程序。有人会问那你们的开发是怎么和其他同事负责的模块进行联调的呢？他们都在自己的电脑上部署所有站点的程序，配置这块，数据库路径连接的是测试环境的地址。有些开发更懒，甚至都没有和其他模块或者站点的程序进行调试（他们大都是这样的），而是直接提交给测试这边的配置管理员部署到测试环境。也许开发人员很有自信心，对自己的编码水平丝毫不存在怀疑，其实也值得我们尊重呀 哈哈。说句实话，好像测试就是开发人员的专职保姆，活不少干，整天忙得焦头烂额，导致自己的测试流程被完全打乱，出不了成绩，被测试的模块一次次回归。好像他们早已经形成了这个大少爷习惯，冒烟测试的工作应该完全由开发人员自己来进行的，现在却成了测试人员来做。这中间我们也意识到无形的矛盾存在，也找过开发的负责人进行协商，我们测试可以出一个配置管理员向他们的开发服务器提交他们的冒烟测试程序，然后他们对自己的程序进行初步验证后再提交到测试环境，再次进行深入的测试。对于该提议，也得到开发部门同事的一致认同，但中间不知道什么原因没有这么做，主要还是领导的执行力度不够，以及部门间缺少这种协作控制的维护体系。
不知道其他公司是不是也有这样的矛盾。
在需求这块，除了大项目以外，很多时候测试人员在开发人员没有提测以前，根本不知道还有这个功能或者变更需求，直到开发人员向测试部的配置人员提交测试版本我们这边才知道还有这个测试。至于要实现的功能，开发人员说产品部没有给什么文档，只有口头一句话或者QQ上一句话需求等。这时候测试部还要去找产品部相关人员调研需求，向他们索要功能需求文档（他们是没有写的，除了大一些的开发项目）。如果不找产品部核对需求，只凭开发人员的一句话，那就只等着翻工的份啦，因为测试部的最终客户是产品部。对于一个IT公司部门协作之间也存在甲方、乙方的关系，尽管没有报酬环节，但这种关系却的的确确存在的。这时候开发和测试是坐在一条船上的，代码的质量以及开发的进度，会影响测试的效率和进度。在同一个公司中我认为的甲方包括公司老板、CTO、公司的某一个部门（产品部、市场部）；乙方包括开发部、测试部。对于领导以及一些人员的一句话需求，开发人员如果定位的有偏差，不仅开发人员要翻工，而且测试人员工作不到位，也必然翻工，对于需求的定位很重要。另外产品部提交不出测试需求文档，测试人员也就没有可以信任的东西写case啦。
总体来说，这些问题的存在在无形之中阻碍了开发、测试的进度，特别是因为需求发起、需求变更引起的问题，给测试人员造成不少的困扰。部门间没有协作控制规范体系来相互束缚，提交需求人员舍不得编写需求文档，久而久之就会产生一种依赖心里，在需求需要变更时，随时一句话就可以变更。测试工作中不仅仅要建立完善的测试体系，在适当的时候也要拉上开发、产品一起来规范这个体系，由于是部门间协作，一定要强硬执行，要让他们知道测试是版本走出家门的最后一道岗。