大家好，我是小谭。
这次思考源于本周的一次测试工作。
发现的问题
先说测试点：
有一个配置弹窗，会设置每台机器是否展示商家的LOGO，默认选择【是】。但是，
如果上一次勾选的【是】，再次配置时，弹窗的选择按钮为【是】；
如果上一次勾选的【否】，再次配置时，弹窗的选择按钮为【否】。
发现的bug：
上一次我勾选并保存的为【否】，第二次配置时，选择按钮仍为【是】。
至此，结束了吗？
非也。
我待测的其他任务需要这个【否】的配置，现在无法配置为【否】，造成我的测试任务阻塞。
于是，我继续追查下去。
因为该配置依赖上一次的保存结果，所以配置会写到数据库，但是我到数据库里查看，没有发现保存记录。
于是，我又尝试保存了几次，发现数据根本就没有落库，后来继续定位，才发现开发在处理此处逻辑时，先用的delete语句，再用的insert，并且两个sql语句不在一个事务里，而insert语句没有触发……
思考什么？
一、测试和开发的边界，到底在哪里
站在测试的角度，我发现了一个问题，完全可以直接提给开发，安心去做其他的事情。
定位bug原因是我的事吗？我花时间定位bug的具体原因，有价值吗？有意义吗？
《学会提问》这本书，有一句是这么说的：一个人有没有头脑，主要的标志就要看他能否提供充足的证据来支撑他的看法，尤其当这些看法存在争议没有定论时更是这样。
抛开这句话的后半部分（不在本次思考范围内），单结合提bug这件事来说——你是否有充足的证据来支撑你提出的bug，是你应当该思考的。
翻译讲究信达雅，提bug是一门艺术，越优秀的测试工程师提的bug越是稳准狠，是你测试专业性的体现。
bug的分类（重要性、严重度、模块化等），bug的具体描述（复现步骤、实际结果、期望结果等），bug的原因等等，都应当成为你测试专业性的标记，缺哪补哪，完善bug信息，提出高质量的bug。
试想，哪一位测试不想要这种评价呢？
二、效率方面的思考
这个bug阻塞了我的其他测试任务，但对于开发来说，在缺乏沟通的情况下，他不一定觉得需要优先处理这个bug，更别说，当你没有定位到bug原因的时候。
而如果你定位到bug原因，并且附言说明你其他测试工作的急迫性，开发解决问题的时间，会在分分钟之内，这对彼此都是一件好事。
一如既往，做个总结
01 提bug绝非想象的简单，优质的bug描述，会带给你不一样的体验；
02 时刻保持提效思维，也是一种间接的提升测试水平的好方法。