如何与测试team协调

开发人员通知测试人员结束了开发或者修改，最后打包一个版本发布到P4上，
测试团队下载此版本，全部回归测试修改的问题，开始在BUG管理系统上提BUG或者重新开启BUG.
开发人员没有事情做，改变角色也做测试的工作，当然是交叉测试避免自己检查自己的代码，发现问题，就开始修改。
最后会变得比较频繁，最后发生了矛盾。
结果测试人员回归一遍很慢。开发人员闲置。而且还出现开发的时候还要解决测试反馈的问题，
主要是由于测试人员不具备开发经验。

怎么才能高效工作？

    

我们的开发在提交测试之前   首先会自己测试一遍，然后出具一份开发人员的测试报告。没有他们自测报告，我们测试部门是不接受测试的。（这点非常重要，能避免很多低级的测试问题）
正式测试之确定一个打回开发的基本点baseline。
根据打回开发的次数来限制开发质量

这样有个弊端   对于着急提交的项目   会造成周期拉长

    1.  适当延长周期   开发从单元测试引入逐步扩展到所有内测。
    2.  适当增加人员同步开发和内测，周期可以不缩短

我认为，有这几个方法：
第一，要求测试部现在不应该做全回归测试，这样开发无法保证。最后才能做的。
第二，及时BUG状态必须注明那个版本修改(这点我觉得是基本要求，而且分支版本一定要正确)。
第三，修改职责表，开发人员不能修改状态，内部进行管理，有开发经理测试批准后，才能变更BUG状态。（这点我觉得有待商榷，得把技术经理TL累死。我觉得技术经理可以控制bug的关闭，而不是bug的流转状态）

然有时候流程是摆设 但是关键时刻还是有用的

但是频繁更新，我认为是测试部在没有稳定的时候，做细致性的回归测试造成的，在没有稳定的时候后这样速度很慢。但是测试部担心的问题很多问题只有全部回归才能发现，针对问题无法发现和确认。

 保证质量的工具和方法很多，但都不能保证100%的正确。虽说理工科专业的人，尤其是好的程序员都是偏执狂，但如何从一个完美主义者变成一个非完美主义者，这是管理和开发本质的区别。事物本身就是这样的，不是非A（1）即B（0）的。项目管理人员尤其要懂得这个道理。

首先，测试部现在没有标准。此项目标准太高了，开发人员开发太低，抱怨我认为是这个项目制定的时候，就没有质量保证的体系。要达到多高，另外测试人员，常常把发现问题和解决问题混问一谈。

个人还有几点经验：

1，重要的是项目经理能否控制QA的绩效，否者，就形成“三权分立”的状态，表面看有利于竞争，实际上不利于合作，这个要把握住度。

2，QA如果经常更换，或者大量新人增加，会延缓项目的进度。因为具有行业复杂度的项目，需要QA深度了解行业知识和基本软件行为，如果经常提出误解的bug或问题，无疑是巨大的浪费。这点很多公司都是反着来，只要觉得是问题，就向上提，造成对QA的误解和作用的忽视。这点需要开发协助QA做好培训，帮助提升自身。

3，测试需要归类问题种类，做到项目过程中追踪，比如某一类问题出现的比较多，这样对项目本身具有一定的指导意义。

4，QA还要和开发商讨有关改动幅度和代价的最佳比例。这点大家恐怕都深有体会。

总之，项目管理就是个双刃剑，发挥好了，非常有用，发挥不好就是绊脚石，毫无用处。