曾经，在一个版本中，提了288个Bug，简直刷新了记录。
可以说，从业这么多年，遇到Bug最多的一个版本。
不过，这个项目也有其特殊之处：
1、是一个全新的项目，版本是V1.0
2、是一个全新的团队，产品，开发，测试是第一次合作
3、功能多，时间紧，编码三周完成的那种
提测完后，总体情况就是点到的地方都会报错，不是后端500就是前端的JS错误。
遇上这种情况，当时是这么解决的：
1、拿着新增的Bug数据，找测试经理汇报，说明质量差的问题
2、知会项目负责人，也就是当时的产品同学
3、在该项目的大群（也就是包含开发经理，测试经理，产品经理），播报每日的Bug情况，主要包含每日新增Bug数，修复Bug数，激活Bug数，关闭Bug数，并附上截图
领导看到每日的Bug数据后，会在群里回复并催促开发同学修复Bug，同时也会强调开发同学自测的重要性。
有了领导在群里的关注，发现质量有较大的改善。
修复Bug的速度快了，质量也没有那么差了。
最后，两周的测试时间，终于测完上线了。
从上而下推动项目，简直比自己推动好太多。
为了改善质量，后续也引进了冒烟流程。
也就是在版本提测之前，开发，测试，产品约个会议室，大家一起，由测试同学现场冒烟，如果主体功能通过，才能进入测试，否则，直接打回。
以后，再也没有出现接近300个Bug的版本了。
划重点：
1、提前介入。
引入冒烟流程，冒烟通过才准进入测试，否则打回。
2、学会向上管理，适时汇报。
自己在只有开发测试的小群去推进项目，一般没有什么效果。在大群，借助领导的力量，效果可以说相当不错，省时省力。
原创文章，转载请注明出处~
