对于一个软件的开发团队而言，测试虽然并不直接参与开发，但是确实对于软件质量是一道保障。唯有他们可以站在终端用户的角度对于系统进行测试。摒弃主管因素的影响，客观的寻找bug，捍卫软件质量。
经常会听到测试和开发在某些团队里吵的不可开交。大有水火不容的趋势。
测试觉得开发不好好写功能，在没有完全验证自己代码功能的情况下就交给自己进行测试，完全是不负责任的做法。
开发觉得测试老是注重一些细节，对于主要功能视而不见。纯粹是小题大做。
遇到项目交付来不及了，还看着测试慢条斯理的测试，开发觉得要抓狂。
开发和测试对于同一个功能的理解不一样，于是，双方围绕着这是不是一个bug据理力争。
以上场景在一个项目团队应该并不少见。首先对于开发和测试相互有敌意，这是不可取的。无论是开发，还是测试，都是自己的职责所在。开发使用软件编码实现客户要求的功能。测试运用自己的能力帮助验证功能的准确性。从某种角度来讲，双方都是为团队为项目出力。出发点一致。
所以基于以上情况，项目经理需要在项目团队中制定一系列的规则，以帮助大家从规则上，或者说从工作范围上明确各方职责。以下是我的一些看法，作为一个抛砖引玉，大家看了可以留言做补充：
一、明确各个阶段的准入准出条件。
通俗的讲，什么样的情况下，开发可以交付测试，即结束开发阶段转向测试阶段？满足什么样的条件可以结束测试，部署交付？这些条件需要在项目一开始就制定下来。并且告诉团队中的每一个人。
比如：在测试用例中选出一部分基础功能，作为smoke test的用例。只要这些用例跑通过了，项目即由开发阶段转向了测试阶段。
这样做可以解决开发随意改完代码交给测试人员测试，而自己却不验证功能准确与否，从而浪费整个团队时间的问题。
二、在Kick off会议的时候，明确测试Leader的权利，即在当前属于测试环节的前提下，test leader有权一票拒绝交付。
可能在这里有人会觉得这样的权利过大，拒绝交付造成的损失担得起吗？
那么我们不妨设想一下，这样的情况：当前在测试阶段，明天要交付了，但是测试leader的反馈是目前系统还存在足以使得系统瘫痪的bug没有修正。如果在这个时候强行交付，可能一时上客户验证不出来，但是到了真正上线之后，再爆发出系统瘫痪这种问题，客户的经济损失就大了。如果牵涉到支付等功能，情况会更严重。
所以如果在这个时候，测试leader提出明天不能交付，就需要注意和衡量了，他所说的理由是否合理。如果当初已经制定，测试阶段的准出门槛是严重的问题完全修复。那么在这个时候，项目经理理应支持测试leader将项目交付延期。
提这一点的是为了解决有些项目到最后实在赶的急了，一边开发还在修bug，一边已经要发布的情况。即项目质量未达到发布要求的强行发布的情况。一旦此类情况产生，感觉测试与整组人为敌。这是不可取的。也是需要避免的。
三、项目进行过程中保持团队相关人员的信息透明。确保开发人员和测试人员对于需求的更改和理解是一致的。
我们在项目进行到测试阶段之后，经常会碰到测试报了一个bug，开发据理力争说这不是个bug的情况。于是两拨人围绕这不是一个bug争论了半天，如果此时项目经理不介入，或者BA不介入，争论会无休无止的进行下去。
为什么会这样？因为两组人理解需求不一致！
这就要求BA在需求讲解的时候，做到开发和测试都到场，让他们理解的一致。在做设计的时候，能够核实功能。在评审测试用例的时候，能够找出异议，在项目初期就解决此类分歧。
当然这类问题不能100%杜绝，但是至少降到最低，那么在正式测试的时候，偶尔发生一两次，BA再做一个澄清，也不会对于项目有太大影响。
综上所述，项目经理在这个时候需要做一个协调人员，不是说站在那一边，找队站，而是通过一些列的规则和沟通，将两队人员拧在一起，达到高质量的按时完成项目的目的。这更多的是考验的项目经理的情商。
