奇门测应期准吗 关于测试排期的那些事

奇门测应期准吗 关于测试排期的那些事

最近有位考友遇到一个关于考试时间的问题，简单说说自己的想法。

问题：

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

由于开发质量差，比如从数据库显示数据到页面的简单功能，三四个页面可以有40+个bug奇门测应期准吗，也有6+个bug被重新激活，所以测试估计周期比较长。

结果项目负责人两次召回了预计的考试日期，让测试的学生真正感受到了项目负责人的意思，但他们并没有主动与项目负责人和自己的负责人沟通。

结果今天测试同学采访了他们的领导，却发现项目负责人已经向他们的领导投诉了很多次，所以测试同学解释了原因，领导恍然大悟并告知测试同学解决办法。

先把每次迭代的Bug数和重新激活数，和项目负责人委婉地谈一谈奇门测应期准吗，让项目负责人下次能妥善控制测试的质量。

其次，对于接下来的 3 次迭代，周期是根据测试的正常质量来估计的。如果没有足够的时间，把bug的数量拿来让整个项目组直接看，推迟交付，坚持3次迭代，如果每次都这样，未来估计周期可以更长。如果质量提高了，大家都开心奇门测应期准吗 关于测试排期的那些事，以后估计期正常。

个人建议：

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

测试日程的长短取决于测试学生的效率、业务的复杂程度、测试的质量以及开发者修复bug的速度等。

在实际估算过程中，首先根据正常的项目质量和人力的配合程度估算工期。如果有上面提到的估算质量差等问题，在执行的过程中奇门测应期准吗，反馈给大家，让大家看到问题，即使后续项目耽误了，项目负责人也能接受。

但是，如果测试同学在他们自己的测试时间开始评估各种风险因素，例如质量差，这对个人和整个测试团队都是有害的。

因为项目负责人看工期，很多时候会忽略质量问题，只考虑业务复杂度和测试效率。如果是很简单的功能，由于质量问题的估算周期长，项目负责人通常首先会质疑的是测试效率。

此类问题涉及部门利益。需要掌握数据，及时反馈。

所以上面的解决方法：先拿数据去找相关负责人谈质量问题，然后做一个正态估计，用3次迭代验证是否可行奇门测应期准吗 关于测试排期的那些事，是一个很好的解决方案.