做测试很多年了，测试过程中会遇到很多形形色色的bug，但哪一种类型的bug，是测试组最难推进的呢？
很遗憾，我如今遇到了，那就是团队协作类型的缺陷，此类属于顽固型bug。
*【缺陷内容】
测试给前端开发提bug，推三阻四不能及时解决掉
*【测试场景】
测试人员回归前端的一个小bug
*【前提条件】
1、测试人员已提bug并提交过禅道
2、开发拖延交付测试，延迟交付
3、改一个老bug，改出新bug
4、做到足够不要脸，死不承认（本不该写，但是缺陷就需要一针见血）
*【预期输出结果】
1、老bug及时修复，且解决方案合理
2、未引起新的其他bug
3、同类型bug，开发能自测，及时修复
4、如需其他人员配合修复的，及时自驱沟通
5、修复好后备注修复方案（有的会产生需求变更）
6、PM对于遗留问题（也就是不解决的）应积极作出明确的判断，与产品经理一起确定上线范围
*【实际输出】
前端开发得到新bug视而不见，常见推锅过程如下：
1、遗留问题-推给之前开发
2、遗留问题-之前没测到
3、遗留问题-之前产品没需求
4、接口问题
5、版本问题
6、UI就这样-设计人员原因
【测试人群】
1、设计组
2、后端组
3、CTO/PM/产品组
4、测试组
*【问题产生原因】
1、开发经验不足，相同问题不会同时处理，基本问题不能提前遇见，不能自测通过
2、开发遇见bug的处理思路有问题，不能正视自己的问题，一心期望是别人原因造成的，跟我自己没关
3、开发自驱动力不足，开发过程中，不会主动积极解决与接口之间的问题，希望别人主动，别人不主动发现问题就跟自己没关系
4、开发人员责任心极其不强，明知道自己程序那么写会出现哪些问题，总抱着应付的心态，对付上线拉倒
5、开发人员面对工作上的问题，无力面对
6、前端开发没担当，出现bug后，应激心里太明显，不以解决掉bug为首选。
7、pm/cto针对此类员工，未能及时摆明自己的立场，优柔寡断、怕担责任、视而不见，不注重团队精神的养成，“小问题大责任、大问题小解决”
6、pm针对于不解决或遗留问题，当开发测试产生分歧时，秉承不主动不解决不积极，应该与产品经理协助开发确认方案，是解决还是不解决。
8、开发经理积极及时友善督促，却反目成仇，得不到开发的理解，认为这也是没事找事儿
9、特殊人群特殊对待，测试人员未及时提前预见此类人，对于开发周期造成的风险，应提前预知，及时应对，如：
做好相关人所有bug的记录；
特别是该类开发的bug前后做好记录（避免不承认、或者偷偷改完后又说没问题）；
针对该类开发，应及时公开测试过程，如提测时间、提测效果、阶段遇见的bug情况、老bug改的过程中产生新的bug情况、bug的修复结果、回归测试的结果等；
10、Pm规划项目计划不合理，对于延期交付环节未及时跟踪和处理，未能根据个人能力判断计划的合理性
11、上线流程不完善，未积极组织需求评审、用例评审、验收评审，以及相关环节内容输出是否合理。
【测试建议】
1、小团队，每个人以身作则；
2、遇到问题，解决问题，不要推卸责任
3、领导不要搅屎棍行为，“小问题大责任、大问题小解决”，这样只会让团队解散
4、必须用例评审、必须验收（避免死不承认，这类人有但是少数），目前在测试的强烈建议下已经进行，但评审过程中，全员还是没有足够重视，依然抱着跟我没关系的心态
5、初级高级开发的区别不仅仅是开发技术，更是一定的专业产品思维
6、企业信任员工，员工才会踏实肯干，不要四处打听，小团队信息是互通的
7、开发版本的迭代内容，确实需要CTO/PM/产品结合实际业务部门情况统筹这些。
【PS强调一下原始遗留问题】
强调一下原始遗留问题，存在的原因：
1、原始需求考虑不周，大家公认，也不说是谁对谁错，因为项目周期短，没有足够时间去评审需求。大家也都是尽可能的本着自己能做到的，尽量压缩个人时间完成的，这一点也不是需 要公司认可给予什么肯定之类的，就是事实如此。
2、有bug为什么还要上线---测试每次上线都会强调遗留问题，至于上不上线，PM会综合考虑，是否上线。
3、原始遗留问题，正常来讲是需要后期迭代的，有些一直没迭代，偶尔遇到都是以BUG形式，开发经理协调尽量完成的。但如果就说是某一个人的问题，也确实不妥。
