在这样的情况下,如果将这个
Bug继续划定在某个项目之下,那么他最多只能为一个项目提供帮助,防止该项目再次出现类似的问题。因此我们各项目组间可能经常能看到这样的对话:
A:Hi,我们这边发现一个问题,具体是…………这样的,你们有相关经验吗?
B:哈哈,这个我们前段时间才遇上过,解决方法是…………那样的。
A:谢谢,谢谢!!
确实,这样的场景很多,甚至能贯以“项目之间善于交流”的美名,但是如果认真地去思考,这样的场景真的有必要吗?如果有一个自动化的平台,会将这些通用的Bug都公布出来,每个人各取所需进行关注、记录,又怎么会出现这样的对话呢?
交流,哪怕是使用最好的方式进行最有效的沟通,始终是有一定的成本的。同时,交流通常是1v1的关系,即便频繁的接触、沟通,一个知识也很难以广播的形式让尽可能多地需要他的人接收到。
正因如此,我才认为一个Bug系统的职责远不止记录、处理、关闭Bug,而应该作为一个知识的集散地,在团队的发展中起更大的作用。
通用性Bug处理平台
前面也提到,对于通用型Bug,平台应该有能力对其进行分发、通告,在这里再详细地总结一下,一个较为完善的Bug平台,在处理通用型Bug方面应该至少有以下的特色:
Bug的tag
无论系统内置使用怎么样的方式来对Bug进行分类,其分类的维度总会有照顾不周之处。因此在Bug平台中应该引入tag的概念,让每一个Bug都能够有一个或多个tag,使用tag这种通用的方式来标识一个Bug的属性,也进一步方便了灵活的分类。
Bug的订阅
在Bug有了tag之后,所有拥有相应权限的人都可以订阅其指定的tag的通用型Bug。当一个Bug被提升为通用型Bug时,Bug平台会找到所有订阅了这个Bug拥有的tag的用户,并通过邮件等形式向其发送该Bug报告。而随后Bug的每一个处理环节都会有邮件等形式的广播。
Bug的共享
在Bug可以被订阅和广播的同时,通用型Bug应该允许每一个有权限(并且此类权限应该放得很宽松)的用户来参与讨论、修补,每一个人都可以提交解决方案,再由相应的QA进行验证后给予实行。这样的效率远大于一个项目的开发人员独自苦苦挣扎,因为很可能有某个人曾经遇上过这个问题,对他来说提供解决方案仅仅是举手之劳。
Bug的生命周期
当前多数的Bug平台将Bug的状态分为几个阶段,一般是Open -> Resolved -> Closed这样的过程,但这其实远远没有涵盖一个Bug处理过程中应该有的环节。
当然作为一个简单、现实为上的Bug系统,其主要环节有以上三者足矣,但是如果需要将Bug平台扩展成一个知识库,就不得不添加更多的环节,以期得到更多的信息:
1、Open,Bug的发现阶段,此时创建一个Bug,通常这个动作由QA进行。任何可重现、不可重现、小频率重现的问题都可以进入到这个阶段。
2、Reproduce Step Confirmed,Bug的重现步骤被确定,通常由QA提交。在这个阶段的Bug通常是稳定的,至少通过QA提供的重现步骤能大概率地被重现出来。