回顾会议上的小纠结

项目组每个迭代的回顾会议通常都是轻松的、各抒己见的。昨天我们的回顾会议上却出现了一个小小的纠结场景。

在大部分人已经贴完自己的反馈小纸条到墙上后，一个开发人员在众目睽睽下手捏自己的小贴纸走到墙面前，却犹豫了，因为他不知道自己写的这条应该贴在“点赞”还是“吐槽”下面。大家哄笑，请他读出纸上的内容。上面是这么写的：“一个功能或界面经历了一段时间没有改变，突然报了一个缺陷，很恐慌!”这位开发人员解释道：“可能是QA的视角在变化，所以有时会在一个很稳定的很久没有代码改动的地方报出缺陷，这个时候作为开发人员我心里挺没底的。比起刚改动过的代码，这种问题通常更花时间去定位。改动后的影响也经常被低估。所以我不太喜欢这种情况发生。但从另外一方面，能够发现问题终归是好的。所以我有点纠结啊，不知道这是一件好事还是坏事。”

唔，这个确实很难界定是好事还是坏事，是应该点赞还是吐槽。还是具体情况具体分析吧！

1、修还是不修

首先我们可以运用基于风险的测试的方法，分析一下这种情况发生的概率和一旦发生的后果严重程度，如果这二者都比较高，那么即使大家觉得有些吃惊、棘手和费时，也需要积极修复和评估修复的影响。如果发生概率不高或者严重程度不高，那么可以酌情商量是否需要修复和何时修复。

在评估发生概率的时候有时需要开发人员花费一些时间和精力去准确定位问题，在没有明确问题根本原因之前其实很难判断这些时间和精力是否是浪费。所以这时还是希望开发人员能够多理解和支持，先找到原因。这和我们去医院看病是类似的。有时花了很多钱做了各种检查却发现之前的危言耸听的诊断是误诊。但这些钱还是要花的。

2、谁的责任

如果这个缺陷是前期需求已经明确，测试人员当时没有充分测试到的，那么应该“吐槽”测试人员的工作质量，督促测试质量的改进。

如果这个缺陷是前期需求不太明确，开发和测试人员都没有想到过的细节，那么这种情况的发生是比较正常的。因为确实随着对被测对象的理解的深入、测试进度压力的变化、测试视角的变化等等因素的变化，测试人员常常会在不同时期针对同一个被测对象报告出不同的问题。发现这类问题对于不断完善系统的质量是有益的。因此，我们希望开发人员能理解这一点，从更积极的角度去处理这种缺陷，不要恐慌。如果开发人员觉得将这类需求并不明确的缺陷报告为用户故事/需求变更更容易接受，那么也可以考虑将缺陷转为用户故事/需求变更。