再谈软件测试过程改进

软件测试过程的改进是一个持续的过程,上一次的过程改进效果显著,具体可参考《软件测试过程改进小记》。于是当新版本的QA报告出来后,测试成员们迅速得召开了内部讨论会,讨论的方式主要是头脑风暴式的,围绕报告的数据,抛出所有的问题,然后再确定目前最急需解决的问题。

于是我们最终确定了应该重点解决遗留bug率偏高的问题。首先解释一下遗留bug率的定义,分母是这个版本总共发现的有效bug数,分子是这个版本发现但未解决的bug数。iOS & Android 这两个客户端的数据大概在20%以上,后台的数据在40%以上(上个版本高达60%以上)。我们从软件研发流程上分析了问题的原因:客户端进入全测试的标准是高单全部解决,中低单80%解决,经过全测试后会产生一些新的bug,这个阶段只要判定为不影响发布的bug都不会解决。提全测试时往往是刚刚达标80%,再加上全测试遗留的一些bug,最终遗留bug率就很容易是20%以上了。至于后台部分,由于没有严格的全测试标准,并且后台功能有些可以设置开关暂时屏蔽,有些可以等客户端提审后再修复,所以遗留bug率是更高的。

基于上述分析,我们在原来的基础上提高了全测试阶段和发布阶段的测试准入要求,比如中低单80%的解决率提高到了90%,我们认为在进入全测试之前修复更多的bug,会有助于提高版本质量。然而实际在和开发的讨论会上,我们遇到了非常大的阻力,原因是开发leader认为他们做不到我们提出的要求,并质疑遗留bug率这个数据的意义,并一再强调能按时完成新需求的开发任务已经很不错了,修改Bug只能看优先级,影响发布的高单是必须改的,其它都可以商量。

会后,我反思了一下为什么会议没有取得预期的结果。其一,分析问题还是停留在了比较浅的层面,bug遗留率高是一个问题,但不仅是表面上看到的这个问题。这个问题还可以继续分解,比如遗留bug的类型分析,以及挂起bug的分析等。其二,在会议之前没有和开发leader沟通会议内容以及期望达成的目标,导致会议时间很长且没有达到预期的目标。这次的过程改进有分歧和碰撞,是挑战也是成长的机会。解决问题的关键还是要解决意识的分歧,只有大家有共识需要解决这个问题,那么问题是一定会有改善的。

(待续)

相关推荐