软件测试过程的改进是一个持续的过程，上一次的过程改进效果显著，具体可参考《软件测试过程改进小记》。于是当新版本的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沟通会议内容以及期望达成的目标，导致会议时间很长且没有达到预期的目标。这次的过程改进有分歧和碰撞，是挑战也是成长的机会。解决问题的关键还是要解决意识的分歧，只有大家有共识需要解决这个问题，那么问题是一定会有改善的。
（待续）