虽然这些bug可能不会被修复，但你仍然要提

在经历过的创业公司中，我经常看到下面这些情况：

• 兢兢业业，认真负责的测试，很容易被认为是一个“事多”的人
• 审时度势，得过且过的测试，虽然人缘颇好，但因为经常背线上的锅，也是颇多怨词

何为事多？就是有一些产品和开发看来没必要提的bug，但仍然被测试提了。

什么样的bug是没必要提的bug，这里面恐怕颇多争议，我们来举几个例子：

bug1：如果老师没有使用授课系统上课，但是布置了作业，进入到查看作业页面时，就会报错“出错了，查询作业失败”（产品的设计是学生只能看到最后一次上课时间至7天后布置的作业，如果老师没有使用授课系统上课，就不会产生上课记录，会导致接口在获取上课时间时出现异常）

产品的解释是，不是bug，设计如此，会告知老师必须用授课系统上课，不会出现没有用系统上课，却在系统内布置作业的情况

bug2：接口在缺少任意一个必要参数时，仍返回200，但是响应内空为空（期望返回400或在响应体中包含报错信息）

开发的解释是：这些参数是必要参数，前端不会少传的情况，少传了也拿不到数据，况且在前端app上已经验证过了，没有漏传，不用修了，或者以后有时间再说吧

bug3：线上预览ppt时，偶尔会出现“唉呀，系统崩溃了”

原因：三方原因，调用三方接口超时或正好三方系统升级时，会出现这种情况

这些都是我在工作过程中接触到的真实案例，总结下来就是这几种类型的bug容易引起争议：

设计如此（by design）

不予修复（won't fix）

推迟处理（postpone）

外部原因（external）

那么这些bug究竟有没有必要提呢？肯定是仁者见仁，智者见智。我的意见是，有必要提，应该提。说一下我的见解：

首先不予修复和推迟处理要分区别下，不予修复，意思是大家都承认是bug，但是不用修复，和推迟处理的区别是，这种bug被认为影响轻微，现在不修，将来也不会修，而推迟处理的意思是虽然本版中不修，但将来还是要拿出来修的。这两种我认为都是需要提的，虽然都不会在本版中修复，但他们确实是bug，是可以反映产品质量的数据。

再说外部原因造成的bug，开发也许会说，三方的bug，提了我们也没法处理，提给我们没有用，要提应该提给三方。我的理解是，这仍然是我们产品潜在的薄弱点，既然被测试发现了，就代表用户也有可能遇到，首先，有bug记录代表我们知道这种情况可能会发生，然后我们可以针对这种情况采取一些防御措施，这类bug的解决方案不一定非得是持续跟进直到三方将其修复才算解决，提出并实施应对方案，也是解决方案之一，如与三方协商不要在用户使用高峰时段升级系统，一旦遇到时采取更友好的提示等。

最后说一下“设计如此”，资深一点的测试也许会说，定义为“设计如此”的bug明显是无效bug了，为什么还有必要提呢？我在长时间内也认为设计如此的bug是无效bug，代表测试没有认真阅读并理解需求，或者说没有参与到对需求的测试中去。但是在经历了数家小公司之后，我改变了这种想法，我不能再以微软这样大公司的规章制度，来衡量和应对小公司，因为小公司往往没有完善的需求评审制度和流程，所以需求本身往往是有问题的，如果你认为产品经理都这么说了，就不再提出来的话，那么你就放弃了代表用户说话机会，而这些迟早会从用户会从嘴里说出来的，到那个时候...上面第一个例子的结果就是很好的说明，后来产品上线后，果真有学生反馈说收不到老师布置的作业，产品各种着急的催促，开发各种检查代码，查看系统日志，各种原因都排查过了，结果就是因为老师是第一次用，没有在系统上上课，直接布置的作业。虽然最终原因找到了，但是这次事故给客户造成的影响却无法评估。记住，永远站在用户的角度，而不是产品经理的角度去考虑问题，这也是我们做为测试的价值。说到这里，出现设计如此的bug，其实有两种原因，一种是测试没有仔细阅读需求，一种是产品没有设计好，那么记录这此bug的价值就是可以反应需求的状态，然后据些做出一些改善，如果大都是测试未理解需求导致的，那就要加强对测试的培训，并针对性的改进流程，如需求评审是否让测试也参与其中的了？如果大都是产品设计有问题，那么就要加强对产品经理的培训，送产品到一线去体验用户真实使用场景，增加需求评审环节等措施。

总结一下，明知bug不会被修复，还是要提原因：

• 记录数据，用来评估产品质量
• 做为产品是否可以上线的条件（计算bug修复率，如果不修的都不提，那么修复率就是100%了）
• 保留依据，做为线上问题是否漏测依据（这一条其实是保护测试的）
• 做为backlog，供将来筛选修复
• 统计意义，分析并挖掘问题根因，推进生产流程优化（单一的问题缺乏说服力，反复出现的问题预示生产流程可能有漏洞。只有记录了才有足够的数据为分析和挖掘提供支撑，而不记录就会造成遗忘，好了伤疤忘了痛，人性如此，况且员工还是流动的）

为什么开发和产品经理会不耐烦？觉得没必要提呢？这里我也分析下

• 处理这些bug需要时间，而这与互联网公司所引导的追求快的理念是相悖的，快速上线验证，快速赢得市场，快速迭代更新。有些有争议的bug甚至开几次会，多次讨论都不会有结果。这样的bug确实不那么招人待见（越是这样的bug，越警示将来可能的风险）。
• bug数量是开发的绩效指标之一，虽然你告诉他：
  • 不是所有的bug都要算到开发头上（例如，设计如此，外部原因，无法重现，重复）
  • 所有的bug都要解决，但不是所有的bug都一定要修复（注意区别解决与修复的概念，如有些bug不影响本次发版的，可以解决为推迟处理）

关于bug的状态以及该如何处理，请参考我的另一篇博文：https://blog.csdn.net/boweiqiang/article/details/102666037

引申思考：为什么测试可有可无？

最开始的研发团队，是没有测试的，严格意义上来说，是没有专职的测试的。随着团队的成长，软件复杂度的提升，当他们觉得产品问题太多的时候，或者投入一部分研发的精力去做测试不划算时，他们觉得需要一个测试。而在当产品没什么问题的时间里，相当一部分人，甚至测试自己，也会怀疑自己的价值，测试就变成了那个多余的，事多的人了。

在国内的创业公司中，普遍存在着对测试的不重视，甚至是不尊重。原因就是他们这种可有可无的地位。

一声唉叹，在小公司测试确实是可有可无。