近期，一个测试朋友遇到了关于测试排期的问题，简单聊下自己的想法。

问题： 组织架构是这样的，项目开发和产品同属一个部门，测试属于一个部门，各自有各自的领导。

由于开发质量很差，例如简单的从数据库显示数据到页面的功能，三四个页面，能有40 bug，重新激活的bug也有6个 ，所以测试估期就比较长。

结果项目负责人两次打回测试的估期，让重新排期，测试同学其实感受到了项目负责人的意思，但是没有主动与项目负责人和自己的领导沟通。

结果今天测试同学与自己的领导面谈，才发现项目负责人已经与自己的领导抱怨过好多次了，于是测试同学说明了原因，领导才恍然大悟，并告知了测试同学的解决方案。

先拿着每个迭代的bug数和重新激活数，与项目负责人委婉地谈一谈，让项目负责人下次适当把控下提测质量，不行可能要打回了。

其次，往下3个迭代，都按正常提测质量来估期，万一时间不够，拿着bug数，直接让整个项目组看，并延期交付，坚持三个迭代，如果每次都这样，以后估期就可以长点了，如果改善了质量，皆大欢喜，以后正常估期。

个人建议：

在测试估期的过程中，一般遵循的原则：测试时间为开发时间的1/3左右，最多不要超过1（当然特殊情况除外）。

测试排期的长短，取决于测试同学的效率，业务的复杂度，提测质量和开发同学修复Bug的速度等等。

在实际估期过程中，先按正常的项目质量和人力配合程度来估期，如果出现了如上所说的提测质量差等问题，在执行的过程中，反馈出来，让大家都看到问题，即使后续项目延期了，项目负责人也可接受。

但是，如果测试同学一开始就将各种风险因素例如质量差，评估在自己的测试时间里，对于个人和整个测试团队都是不利的，因为项目负责人看工期，大多数时候会忽略质量问题，只会从业务复杂度和测试效率去考虑，如果很简单的功能，由于质量问题估期很长，项目负责人一般首先质疑的是测试效率。

这种是涉及到部门利益的问题，拿着数据，及时反馈，是很有必要的。

所以以上的解决方案：先拿着数据去找相关负责人聊质量问题，其次正常估期，用3个迭代来验证是否可行，是不错的解决方案。