四、项目实施经验教训
测试作为项目开发的后一环，错误、延时、疏忽等都可能在测试阶段表现出来，如何有序管理和分析各种问题对质量控制和过程改进非常重要，使用web based系统是一个好的实践。
在项目组内，对Bug采用数据库系统进行跟踪并不困难，因为主要是测试人员提交Bug报告，测试人员使用多，相信测试人员对使用中心数据库的好处是很了解的了，只要项目经理支持很好办了。如果要对其他缺陷，如需求变更，也这样管理不是那么容易了，在技术上当然没有问题，难在工作方式的改变，虽然用Email和文档管理无法实现工作流的自动化，也不如数据库系统提供那么多的分析和报告选项，但在小规模的项目中依靠人工管理也可以做得井井有条。我们在多个项目的实施中遇到这样的情况，有的项目随时都有需求变更，而且变更的数量不少，项目组主动提出想用数据库系统来管理；有的项目刚起步，第一个阶段的开发业务功能不多，推行的时候阻力很大。我的初级目标是有序地管理错误和变更，在实施手段上有冲突时，不要操之过急，融洽的关系对项目的成功是很重要的。往往是有了成功的案例后，回头推广又变得容易了。实施新过程时好先局部试点，采用PDCA循环，不断总结经验，再推广。
使用缺陷数据库，可以制作得到各种缺陷分析图表，从而预测项目风险或解释测试结果。下面两张图都是Mantis生成的缺陷图，从累积错误打开图，分析错误生成趋势，在发现错误报告未收敛时发布软件，显然风险很大，当然使用图表时还应结合实际，在曲线平坦时，是否开展了测试工作，曲线上升时，错误的严重性等级如何等。从严重性等级的柱状图可分析被测系统的总体状况。在发布管理不规范的组织中，当产品质量问题突出时，测试组可以通过解释这些图来阐述测试结果，从而规范发布过程。
第一部分提到的根本原因（Root Cause）域，他有助于使开发人员的注意力集中到引起严重、频繁问题的领域，从而消耗少的资源改进过程取得显著的成果，这是我在过程改进时常用到的80/20法则。在项目实施时，实际情况并不理想，因为开发人员忙于改Bug，少有主动写错误发生的根本原因的，这需要开发人员的配合和管理者的支持。
缺陷数据的使用应谨慎，不要将错误个人化，应保证数据的真实性，否则数据对过程改进没有意义。
实施过程中，大家会对工具提出很多需求，应评估哪些是共同需求、核心需求，系统修改复杂程度，对当前系统和系统升级的影响。测试组在实施过程中，对不同角色人员的工作流程有了深入而准确的了解，同时可以进行工作流程的改进。

使用开源系统的利弊
由于开源系统的代码是公开的，用户可自行维护和定制，大家也可以提交新特性和功能扩展要求，而不必受制于商业系统的制造商。开源系统的用户遍布世界各地，Bug反而容易发现，同时公开源代码中低效率的程序也容易被发现和修改。当然越是流行的软件，生命力越强，Bug清除和新特性增加越快。
开源系统与其他工具的集成比较差，不如商业系统提供整个软件开发生命周期的工具的集成，如项目管理、需求管理、建模、自动化测试、缺陷跟踪、配置管理等有机集成，实现整个开发流程的自动化。但一般的中小企业，大多没有实力配置全所有系统，另外，不同厂商优势不同，主导系统也不同，有的企业需要根据自身的特点选择不同厂商的工具，所以即使购买商业工具也未必能将所有系统很好地集成。
开源系统是免费的，但有人提供收费的系统维护和定制服务。
五、小结
本文主要探讨缺陷跟踪管理的流程、工具和实施问题，缺陷跟踪在技术上并不难，而是难在管理上，好的工具有利于管理和交流，的项目组应意识到有效的交流方式是多种多样的，不应该单依赖系统，这样才有利于提高团队的战斗力，而不是把重点放在追求系统功能的十全十美。有些缺陷跟踪系统有Knowledge Base 功能，这对公司知识库的累积也很有效；有的系统对不同用户生成相关的To-Do-List，方便日常工作；有的对每个发布版本都有详细的缺陷报告。总之，花费时间和精力完善错误管理系统是值得的，这是质量管理和提高的基础。
参考书目
《测试流程管理》 北京大学出版社 作者Rex Black 2001年3月第一版
《CVS开源软件开发技术》 机械工业出版社 作者Karl Fogel 2001年6月第一版
关于作者
蔡琰，外企QA主管，有三年电子商务领域QA、测试主管经验及多年的开发经历。目前关注基于J2EE构架的web系统的功能测试和性能测试、自动化测试、过程改进。现在上海，您可以通过电子邮件cindy_cai@sina.com 和她联系。