《Google软件测试之道》一书中介绍了谷歌公司管理Bug的一些经验，其中不乏我们可以借鉴之处。
其一，Bug数据库是开放的。
Bug数据库是开放的，可以带来两个好处：
一是任何人都可以给任一项目提交Bug。
任何人，指的是不限职务，不限部门，不限项目，只要有人看到软件问题，就可以提交Bug。
这样做的好处是可以让更多的参与软件质量过程，更容易发现软件的Bug。
而我们实施GJB5000的组织，软件Bug通常仅限于本软件的软件测试人员、质量保证人员、系统/组件设计师（系统联试或实验时软件问题的提交），这个提交Bug的人员范围是极大地受限的。这就意味着发现软件Bug的效率也会较低。
虽然由于保密的原因，能够接触到一个带有密级的软件的人员范围必然有所限制，但也应该在不违反保密要求的前提下，让更多的人参与进来，都有提交Bug的权利和责任。
否则，全面质量管理，全员参与质量管理，就是一句空话。
二是开放的Bug数据库可以充当预防错误的经验教训库。
质量大师克劳士比提出的“质量免费”的概念，其理论就是建立在预防错误之上。如果一个开发人员在正式开发软件产品之前就了解到类似项目出现的Bug，他就有针对性地进行设计，避免这些Bug再次出现，那么他所开发的软件就有可能不再出现Bug。
而开放的Bug数据库就有可能帮助他实现这个目标。
再退一步，即使他没有做好设计，Bug仍然出现了，他也可以根据Bug数据库中的处理方案轻松地解决这个Bug。
其二，描述Bug的状态是详细而具体的。
谷歌公司描述Bug的状态有7种，非常详细而具体，包括：
新建：Bug刚刚创建，尚未指派。
已指派：Bug已被指派给某人进行修复。
已接受：某人接受了指派。
以后修复：指派给的人决定推迟到将来解决Bug。
不修复：出于某种原因，指派给的人决定不去修复该Bug。
已修复：Bug已经被修复，但结果尚未验证。
验证者已确定：指定某人验证Bug修复结果。
已验证：Bug修复结果验证通过。
与其相比，我们的Bug状态通常只有新建，修复中，已关闭等几个状态，不能准确地反映Bug修复的进程，也不能反映以后修复、不修复这样的处理方式。
这正是：
问题数据要开放，全员参与做质量
预防错误也方便，状态详尽更在行
参考书目：Google软件测试之道，作者：(美)惠特克(Whittaker，J.)，(美)阿尔邦(Arbon，J)，(美)卡罗洛(Carollo，J)，译者：黄利，李中杰，薛明，出版社：人民邮电出版社
联系客服
