测试bug管理流程

    关于测试bug的各个状态，大家大概都知道了，我就不多说了。最近带领了一个项目，bug测试总数 530个，修改了510多个；看这个数字还是很欣喜的。这是目前我带领的测试bug数最多，修改率最高的一次；总结了一下经验，其实是测试bug的管理流程比较正确；

    首先介绍一下我们公司现在开发团队的情况，大家都没有意识到要修改测试bug，包括项目经理都没有意识到。因为大家已经习惯了原来的开发模式，起初我会每个问题跟他们过一遍，但是后来发现那样太麻烦，效果也不好。最后我终于采用了一个比较好的模式；

1、我提交bug到bug管理工具TD上面，每天固定时间发送问题列表，同时将每个人有多少bug没有解决，有多少bug解决了统计在正文中；

2、每天固定时间，我让开发人员看一遍bug将修改的问题bug号回复给我，（我们用的TD，但开发的都不上td），没有回复我的，我会去找他们；

3、然后我再复测大家修改的bug；

    看一下这个流程也很简单，但最重要的是，每天让他们固定时间回复我的问题，我把这个环节重点拿出来强调了。因为开发人员没有习惯自己看问题列表回复我，所以我要所有的团队成员有这么一个意识，培养他们良好的修改bug的习惯，而且是每天固定时间要回复一下；这样真的还起效了。呵呵，虽然项目测试了这么多bug，但仍然还有很多问题，由于版本的管理混乱，没有自动化测试工具，造成重复手工测试用例的工作量很大。所以，我现在在研究一下自动化测试工具看看能不能用上；

    顺便说一下，这个项目的开发负责人很负责人，我们也共同学习了很多东西，呵呵，没有她的支持，估计也不会有这么好的效果