老Q讲完这些内容之后，大家觉得获益匪浅，对缺陷跟踪的重要性也完全理解。但是，对缺陷跟踪的流程还是觉得太复杂了，表格中的子系统、模块等信息每次都要重复填写，确实很费时间。这点老Q倒是真的可以理解，因为他自己也快被折腾得不行了。现在的流程是这样的，如图6-3所示。
图6-3 缺陷跟踪流程
■测试人员测出问题后，记录在《测试缺陷记录表》上，然后交给老Q。
■老Q抱着一堆表格去找开发组长，由他进行分类和判断后，再像邮递员一样分给不同的开发人员。
■开发人员修改完成后，把《测试缺陷记录表》陆续还给开发组长，开发组长看看没问题就还回老Q。
■老Q拿着返回的《测试缺陷记录表》再去找测试人员，测试人员重新测后如果问题解决了，就在《测试缺陷记录表》进行确认；如果没有解决，返回重启流程。(www.xing528.com)
■全部完成后，老Q把这些登记表归档收藏。
这个流程本身没有问题，完全能保证发现的缺陷被有序地解决。但是，因为使用的是纸质表单，过程中涉及的人员多、步骤多，往往不知道哪张表单到了哪里了。为此，老Q设计了一张表格登记所有的记录单，并不停地更新状态，但是缺陷多了疲于奔命也来不及登记这么多的单子。特别是如果有人想查阅以前某张表单，老Q就要翻箱倒柜地找好半天，感觉自己头都晕了。
在场的工程师都说，我们都是做软件的，完全可以开发一个管理工具，这个工作并不是很复杂。如果有工具，信息记录在系统中，老Q就不用手工收集、传递表单，像个邮差一样跑来跑去了。
老Q听了之后感动极了！众人拾柴火焰高，几个自愿者主动利用业余时间帮助老Q开发缺陷跟踪工具。他们先从网上找到几个不错的开源工具作为雏形，然后根据老Q的需求进行一些必要的开发，设置好了流程、角色和用户权限之后，真的跑了起来。老Q试了试觉得非常好用，就召集项目组的成员做了个培训，然后就开始正式使用了。
有了这个系统之后，提交、判断、分发、修改、复核、关闭的全部步骤都在系统中管理。测试人员发现缺陷后直接把问题记录在系统中，很多信息可以根据用户自动带出，一些选项也是通过下拉菜单选择，省了测试人员不少纸面工作。测试人员输入之后，老Q和开发组长立刻就能看到完整的缺陷清单，判断缺陷类型和严重性后自动分发给相应的开发人员。开发人员可以直接看到自己的缺陷修改任务，并能够按照优先级进行排序。测试人员也可以直接在系统中看到已经完成修改的缺陷并进行重测，直到问题关闭。这样不仅减少了纸面工作，而且流转的速度也快了很多。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
