3.3.3 增加风险bug的审核流程
根据软件bug出现后带给用户的影响程度，bug可以被定义为不同的等级[bug等级：根据对用户的影响程度，软件bug通常划分为致命、严重、一般、次要和轻微 5个等级。在实际应用时，使用者可根据行业情况、软件特性需求，对bug等级进行扩展、裁剪或局部重定义]。本节所述的风险bug是会给产品的使用者带来不良影响的严重及严重级别以上bug的总称（如分子诊断检测仪因存在软件bug，使得病人样本的检测结果不准确）。接下来，Sherry首先介绍了软件bug处理的常规流程，然后针对风险bug，给出了优化后的处理流程。优化后的风险bug处理流程可以让开发人员的代码修改更加彻底，让测试人员对bug的回归测试更加充分，从而降低风险问题的发生，提升产品质量。
Sherry介绍说，当她们的项目团队成员只有十几个人的时候，软件bug的处理流程如图3-15所示。
图3-15 软件bug处理的常规流程
尽管bug分为不同的级别，但在故障管理系统Bugzilla中的处理流程是一样的。测试人员在提交风险bug时，要求统一提交给某位资深开发工程师，由他保证bug处理的质量。风险bug解决后的回归测试统一由某位资深测试工程师进行，从而保证回归测试的充分性。由于团队规模小，就单个项目的开发而言，Sherry带领的团队在采用图3-15所示的软件bug处理的常规流程时并没有遇到太多阻碍。
而随着公司业务的快速增长，软件团队扩大到100多人，在并行开发多个复杂项目时，故障管理系统Bugzilla中的风险bug成倍增加。Sherry说，此时，她们的团队遇到下列3个突出问题。
1）团队规模扩大，原来“风险bug提交给某位资深开发工程师解决”的要求在执行时经常被遗忘，因为在默认情况下，故障管理系统Bugzilla会自动将测试人员提交的bug指派给bug所属功能模块的开发人员，而测试人员此时就容易忘记重新指派解决责任人。
2）原来的bug处理流程在执行过程中不时出现混乱，如新入职的开发工程师被指派负责处理风险bug，但由于其业务熟练度不够，解决问题的经验也不足，经常出现已解决bug被重复打开多次的问题，使得bug处理质量不受控。
3）测试团队中的资深测试工程师短缺，新员工需要参与对已解决的风险bug的回归测试，但不时会发生回归测试不充分的问题。
下面是Sherry带领的团队在经过不断的探索后发现并成功应用于多个项目的解决上述问题的方法。
（1）风险bug解决后，增加系统工程师的审核流程
在开发工程师初步解决风险bug后，测试工程师回归测试bug之前，增加系统工程师对解决方案的有效性、完备性的审核，从而降低测试工程师回归测试bug时重新打开的概率，防止未彻底解决的风险bug重新回到开发人员手上，减少修改的次数。
（2）风险bug验证后，增加测试系统工程师的审核流程
在风险bug解决后，其解决方案由系统工程师审核通过后，由测试工程师进行回归测试，回归测试完成后，填写回归测试策略，并把bug状态置为“已验证”状态，然后由测试系统工程师进行审核。若测试系统工程师审核通过，则关闭bug；若不通过，则反馈意见，由测试工程师重新进行回归测试，直到审核通过关闭bug为止。
（3）风险bug的审核流程自动化
优化故障管理系统Bugzilla，在风险bug被开发人员解决后，由该系统将责任人自动指派给系统工程师。同样，风险bug在由测试工程师进行回归测试后，由该系统自动转给测试系统工程师处理，以解决人工手动指派责任人经常忘记的问题。
增加风险bug审核机制的流程如图3-16所示。
图3-16 增加风险bug审核机制的流程
Sherry说，从测试报告的数据来看，此流程执行半年后，多个项目的风险bug数量明显得到控制，在多名员工的总结中，也明确提到一些之前常出现风险bug的功能模块的质量得到好转，乃至整个软件系统的质量得到了较大提升。
