关于测试排期的那些事

上一篇 / 下一篇  2021-12-21 17:34:14

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


问题:

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

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

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

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

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

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


个人建议:

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

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

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

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

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

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

ps:我是lc馨馨紫,全网名称统一,期待优秀的你关注我~

原创文章,转载请注明出处~


TAG:

 

评分:0

我来说两句

lc馨馨紫

lc馨馨紫

公众号「lcxinxinzi」,测试工程师|待过大厂|带过创业团队,爱给开发提Bug的测试妹纸一枚,面试资料和大厂内推+V:Icxinxinzi01

我的栏目

日历

« 2022-05-16  
1234567
891011121314
15161718192021
22232425262728
293031    

数据统计

  • 访问量: 1659
  • 日志数: 13
  • 建立时间: 2021-10-29
  • 更新时间: 2022-03-09

RSS订阅

Open Toolbar