搜狗输入法通过BUG流程优化，降低BUG修复分歧

张经理是一家成熟互联网企业的测试主管，这段时间要为一个新成立的项目招聘几位测试工程师。本次参加面试的童鞋，都是有一些有工作经验的测试工程师。

张经理在吧啦吧啦问了若干技术问题后，提了一个问题：以前的工作中，遇到哪些事情觉得是有难度的？

约60%的测试工程师，都提到，在BUG修改意见和开发人员有分歧时，说服对方修复bug是一件有难度的事情。

那么今天我们就聊一聊，当测试人员和开发人员BUG修改意见不一致时，我们的项目进行了哪些调整。

首选，测试或产品反馈提交的bug，开发不认可的原因大致可以分为以下几类：

1、开发的确认实现是正确的；
2、开发当前懒得去改；
3、涉及到自身的考核；

针对这些原因，导致这个问题的根本原因可能在于，开发与测试之间就这个问题缺乏一致的标准。为了达到标准统一，我们在BUG流程上进行了如下优化。

1. 搜狗输入法的BUG流程中所有不修复的BUG都要经过产品、开发和测试三方的评审和确认。

不修复的问题都要经过开发、产品和测试三方工作人员的评审，并经过三方经理的确认。

三方会从技术实现难度、用户交互体验、BUG不修复对产品或者项目带来的影响去思考。

如果修复难度较大，但影响不大、发生问题的几率微乎其微，那么可以考虑暂时放过。

如果影响较大，那么测试要把情况告诉开发和产品，由开发和产品判断。如果开发还是不认可，而测试认为自己的判断是正确的，测试可以和开发经理、产品经理进行意见沟通；或者扩大测试范围，参考更多样本集，如公司内测、内测群内测等小范围实验~

2. 不修改的问题支持多样的处理结果。支持不是问题、任务取消、申请长期遗留、技术不支持。

不是问题：包含理解分歧，导致意见不一致，经过多方确认后，意见一致，确定不是问题。也包含，需求变更后，原有的问题，变更为不是问题的情况。

任务取消：任务中断或者取消。

申请遗留：开发申请在当前版本不修复。

技术不支持：当前开发手段无法支持需求实现。

3. 不修改的问题需要公示不修改的原因。

4. 搜狗输入法对开发申请遗留的问题，在遗留bug修复版本，支持标注升级包修版本修复或下一个大版本修复。

升级版修复，是在下一个升级版或者下一个小版本修复。

下一个大版本修复，是在下一个大版本进行修复。

当然，为了方便操作，我们这些流程，都是使用cynthia任务的BUG系统进行管理的，并不需要花费很多时间。

5. 我们的项目并没有把测试发现BUG数量作为开发的考核项。

不同的功能，BUG数量可能会有巨大的差异，比如功能模块涉及兼容性，那有可能这一个功能，就会发现80多个BUG。而不涉及兼容性，基于算法的功能，如排序可能只有3~5个BUG。所以我们更多还是关注BUG修复比例和功能上线后的项目质量。

经过这些流程上的调整，输入法项目，有分歧， “输入法项目中有分歧需要当面argue”的BUG比例低于2%，大家配合起来还是比较愉快滴~

原文链接

如需转载该篇文章，请注明来自“搜狗测试”