看法2：

　　如果我是小王，那么此时我到是觉得我必须要尽职尽责，对目前系统存在bug进行归类总结，分出bug的优先顺序以及bug出现所属rootcase，并更具这些归类做一个整体的解决方案，然后尽可能的去和开发人员进行沟通，尽可能做到既不影响当前的开发进度又能解决这些bug，当然解决bug的前提是以及你掌握的优先级的，比如决策性的bug、逻辑混乱的bug等等那是必须需要当即进行修正的。

　　同时了，此时和老板进行交流时，我想不会是用一堆bug来和老板面谈了，而是说目前系统存在了bug，而现在我制定了解决bug的方案，我也尽力说服大家来对bug做修改了，同时也保证了开发进度。

　　看法3：

　　1、缺陷等级不一定等同于优先级。问题的严重程度并不一定取决于问题的技术性质。很多项目，问题是否能得到及时解决取决于该功能是否常用，影响面是否广大等因素。至于说到缺陷等级是否变更，我觉得要看你这个缺陷等级所要表述的是什么概念。

　　2、看了这个问题，前面的问题，即缺陷等级，可能偏向于缺陷本身的性质这样一个概念。那么，的确存在相关因素会导致这个bug的修改优先级发生变化。例如：形象因素等等。

　　3.1 Bug修改与否，取决于较多因素，常见的是以下几种情况

　　3.1.1 bug本身的性质

　　3.1.2 Bug的影响面，是否会影响现行业务或对业务支撑造成不可弥补的错误

　　3.1.3 不修改会存在巨大隐患么？

　　3.1.4 客户关注

　　3.2 客观而言，不会。有影响的只是项目终交付的时间和进度计划。当然，随着项目推进，之前的bug可能会被冲叠，造成隐匿，这种情况的隐患极大。所以，必须强调的是Bug修改优先于新功能开发。

　　3.3 这种情况好不要出现，一旦发生，即意味着项目可能会出现较大的不可控因素，导致质量的急剧下降。除非，这块功能不再使用，或之前的需求存在漏洞需要重新考量。

　　看法4：

　　1、个人认为不应该变化。

　　2、严重等级一般不会发生变化，而发生变化的可能是优先等级，这是两个概念。

　　3、修还是不修，主要是看这个BUG是否在进度的关键路径上或核心功能模块，如果在那么必须干掉，否则可以postponed；进度和资源当然有影响，这些都是需要项目团队及早的做风险管理规划的，如果协调不好资源和进度，那么非关键路径上的问题可能会成为关键路径上的问题，那么这个时候对团队的执行决策产生影响；发现的BUG应该都要修的，只不过会根据进度安排，把一些不重要的BUG推迟到下一个版本修复

　　看法5：

　　这件事说明一个问题！测试人员在公司的生存状态！换成我，我也不会妥协，Bug可以pending，但是不能一直拖下去，你们公司如果这样发展下去，迟早要出问题的！我现在会定期去查看Bug状态分析图，如果open的bug多的话，我会要求开发暂停新功能的开发，先处理Bug，我想这样是对公司，对客户，对自己负责，测试有时候要强硬一点！

　　上述的看法我觉得没有谁对谁错。因为不同的公司和不同的项目特点，决定了解决问题的方法会各有不同。从国内的不少技术社区了解到，很多人觉得国内测试水平比较落后，其中例子有比如没有统一的规范，对测试不够重视等。这里我会尽我所能对测试领域做一些分析和讨论，希望有所帮助。