围绕Buganizer的产品流程

做技术的一定知道缺陷跟踪系统（bug系统），更不用说做测试的了，不过普遍都认为这系统是用来记录bug的，其实在google内部，这套系统是产品/项目围绕的核心。Google Buganizer扩展了类型，包含的不仅仅是缺陷，还有功能需求、流程、客户问题等，今天就来介绍下围绕这个系统是如何将产品所有人员联系在一起。

 

1. Bug

这个就不说了此处略过，只要是缺陷，都会登记到系统里，无法重现的bug也必须登记，对应的开发进行了修复，匹配上changelist（CL），这个CL进了哪个release，验证是否通过，主要是一个测试和开发沟通的过程。

同时开发自己也可以给自己开bug，比如他在实现某个功能过程中进行了单元测试，冒烟测试发现的bug都可以登记到系统中。

2. Feature request

功能需求通常一些公司的做法都是从需求文档开始的，不过在google，却是首先创建一个feature bug来跟踪，在bug中产品经理添加PRD，开发添加Design doc和编码实现后的changelists，UX添加UI mock，测试添加Test cases，这样所有参与人员都通过这个bug来沟通，当然各种文档通过Google doc来分享。那么从这个bug中我们可以看到一个功能的整个生命周期。

功能需求并不仅仅是产品里的需要实现某项功能，还包括希望对某个功能进行自动化测试、希望提高某模块性能、希望对某部分代码进行重构（不过这个一般会使用internal cleanup类型）

3. Customer issue

这个大家应该比较熟悉，就是客户反馈的bug，因为测试无法穷尽测试，比如某些场景、某些环境通过客户的互动反馈登记bug。通常线上产品都可以提供一个客户反馈的入口，让客户登记问题自动提交到bug系统中。

测试人员通过对客户反馈的分析来决定是否有遗漏的用例，补充到测试用例中。

4. Internal cleanup

一般给代码级别使用，比如对某部分代码进行了重构，需求的变更导致数据字段的变更需要迁移，自己对某段代码的优化。

5. Process

一般发布时使用，在google很多产品的发布周期是weekly或bi-weekly，那么假设在每周的周五（不同产品可能选择的周几不一样）会cut到某个CL，或是从rapid中挑选一个通过测试的release candidate(RC)，

通过这个bug可以跟踪整个发布过程，如果这个RC出现问题，指定给对应的开发，如果没有P0/P1的bug，那么正常发布上线。

 

Google's Buganizer

http://verneharnish.typepad.com/growthguy/2007/06/googles_buganiz.html