当你的bug遇到不予解决、设计如此就算了吗

问题1：在测试发现问题时，是先跟研发沟通还是先提Bug？

解决：

在测试项目的初期，对程序不熟悉的情况下，可以先沟通，再提Bug；

后续对项目熟悉了，理论上是先提Bug，必要时再沟通（偶现或可能是偶现的问题；录像回放的问题）

原因：

对于测试人员来说，是站在用户的角度去测试，认为不可接受的，那90%以上（排除操作上的错误）属于是问题，不管是哪边的问题，总是要解决的，所以没有必要所有问题都要先跟研发沟通；

偶现问题必须沟通，以免破坏环境，后续不好定位；

回放问题要及时通知研发及时定位，以免录像被覆盖或被格式化。

先去沟通对双方的工作打断和耗时，也是个考虑的因子。（共同的一个团队，共同目标是为了更快更好的产品，减少内耗）

问题2：测试出的问题，研发说是工具的问题，如何处理，是否要提单？

解决：

找产品线的发布程序来测试，并跟产品线测试人员沟通，若产品线也说是工具问题，那可做认可处理；

使用其他合理的第三方工具测试，比如VLC的问题，可以用Quicktime player再测试一下；

产品线测试人员不知道或没遇到过此种情况（有可能是项目的特殊/新功能），研发也认定是工具问题，需要有项目经理同时确认是工具问题，并在问题后面添加注释，写明是工具问题，方可做关闭处理；

工具固有问题也需提单；

原因：

对比测试，若产品线发布程序也有该问题，那说明是产品线研发定位过的，可做认可处理；

一个研发说是工具问题没有说服力，需要有项目经理同时认可；

提单留作记录，若后面测试人员再遇到类似问题，有单可循，不需要再花费时间去确认；

问题3：测试出的问题，研发A说是外部原因问题，如何处理？

解决：

研发A首先定位，写明定位结果，然后将问题转出给对应部门的研发B（邮件或者禅道指派的方式）

若研发B有回复，说确实是他们的问题，短时间内，研发B修复，研发A重新打包，测试人员验证，验证通过，关闭；

若研发B有回复，说确实是他们的问题，长时间内都未修复，或不可修复，要么研发B邮件回复承认问题，说明一个修复时间或无法修复的原因；要么在禅道上添加备注，证实确实是自己的问题，禅道里需添加一个新的问题状态，以区分这类问题；

若研发B不承认是他们的问题，需要研发A继续跟踪问题，且问题不可关闭；

外部原因问题也需提单；

原因：

就算问题是外部原因，其表现也是在我们的产品上，所以，不管是哪方的原因，问题始终都是要修复的，所以外部原因的问题，理论上来讲，是需要跟踪到问题修复的；

提单留作记录，若后面测试人员再遇到类似问题，有单可循，不需要再花费时间去确认；

研发认为的重复bug？

解决：

重复问题表现的现象不一样的也应提单，且不应定义为重复问题；

原因：

从研发角度考虑，定位出来的是一个原因导致的现象不一样的问题，所以可以定义为重复bug，但是，从测试人员的角度考虑，认为现象不一样的问题不应认定为重复bug；

在客户使用的过程中，只会看问题的现象，而不会专注于问题的根因，所以现象不一样，根因一样的问题也不应定义为重复bug。