3.3 优化bug处理流程
3.3.1 定制合适的bug处理流程
测试人员需要对工作中发现的软件bug进行规范管理，这样才能及时、有效地评估及修复bug。在软件开发过程中，bug处理流程就像一根将bug的相关专业方向人员串联起来的纽带，如图3-11所示。不同专业方向人员围绕出现的bug，按照一定的流程解决bug。
图3-11 bug处理流程
图3-11展示的是一个bug从被发现到被解决的整个过程，也就是需要经历“提交”“解决”和“关闭”3种状态。修复bug存在诸多困难，往往很难一次性彻底解决一个bug，这使得bug可能被测试人员重打开。有时，bug并非来自软件内部，而是涉及第三方软件组件、硬件组件和机械组件等，这类bug属于产品的其他专业方向需要解决的bug。此时，bug解决流程的走向需要改变，也就是将这类bug转给其他专业方向的工程师解决，如图3-11所示，经SE分析后，转给OE解决。在定制跨专业的bug处理流程时，我们需要综合考虑产品的各个专业方向，以便bug处理流程能够及时、准确流转。
3.3.2 简化bug提交的审核流程
Sherry所在的公司采用的故障管理工具是开源的Bugzilla，尽管此工具集成了一套成熟的故障管理流程，但根据团队内部的需求，她们对工具的一些功能进行了二次开发。一开始，Sherry带领的团队只有10个人，且新入职的测试工程师较多。为了提升提交bug的有效性，Sherry要求所有新人提交的bug都要先提交给她，由她审核确认后再转发给开发工程师，如图3-12所示。这样做的好处是流转到开发工程师的bug基本都是需要解决的，因为作为测试负责人的Sherry已提前过滤掉了新人提交的无效、重复、描述不明确的bug。
图3-12 测试负责人审核提交的bug
由测试负责人对提交的bug进行审核的方式确实可以明显提高提交bug的质量，但Sherry平均每天需要付出1～2小时的审核时间。后来，Sherry带领的团队扩大到上百人，每天向故障库中提交的bug成百上千。显然，提交bug的人工审核机制已经成为项目的瓶颈，以致一些bug不能及时得到开发人员的关注及解决，从而影响了项目的整体进度。于是，Sherry带领团队成员优化流程，提出了一套测试工程师在bug方面的自管理机制，包括填写bug提交前的检查单和设立bug排行榜，同时改进了Bugzilla内置流程，让bug提交后能马上流向关键的开发端。
（1）测试工程师填写bug提交前的检查单
测试工程师在提交发现的bug之前，需要填写表3-5所示的检查单。
表3-5 bug提交前的检查单
填写bug提交前的检查单看似简单，但需要测试工程师具备主动沟通、信息搜索和描述规范等能力。当全面浏览测试人员每天都在面对的故障库时，我们会发现，即使公司有明确的流程规范、模板指南等，但总会有执行不到位的案例出现。例如，bug的严重程度填写不当，根据故障提交规范中bug级别的定义，一些bug本属于“严重”级别，却被填为“一般”级别；bug的发生概率填为“必发”（必然发生），但按照出现bug的步骤的描述进行操作，却不能重现bug，在与bug提交者确认后，发现它是一个偶发（偶然发生）bug。于是，针对表3-5所示的bug提交前的检查单中的第3点，即测试人员对bug的描述不符合公司的故障提交规范等问题，Sherry带领的团队设立了“bug排行榜”。
（2）设立bug排行榜
在引入上述bug提交前的检查单后，针对故障库，Sherry带领的团队新增了一个bug排行榜，如图3-13所示。bug排行榜可以直观展示bug情况，还可以促使团队成员相互监督。针对不同的项目，bug排行榜会列出与bug相关的不同维度的数据，包括每名测试工程师提交的bug总数、无效bug数、重复bug数、已解决bug数、被重打开的bug数和关闭bug数。另外，量化的bug数据有利于对测试人员进行考核。
图3-13 bug排行榜
在bug排行榜的推动下，测试工程师填写bug提交前的检查单，然后提交有效bug，开发工程师对提交的有效bug进行处理，形成“双赢”局面，如图3-14所示。我们可以看出，在bug提交的过程中，Sherry省去了以往人工审核提交的bug的时间投入，每位测试工程师通过“自管理”bug的方式，快速、有效地提交bug，不仅锻炼了自身的测试能力，还可以避免开发工程师处理无效、重复的bug。
图3-14 优化后的bug提交流程
