围绕Buganizer的产品流程

时间:2022-08-19 16:55:39

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

围绕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系统中。

围绕Buganizer的产品流程围绕Buganizer的产品流程

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

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