为了便于大家理解，在开始谈如何提交有效缺陷这一问题之前，想先和大家谈谈关于“吐槽”的观点。
“吐槽”一词，是指从对方的语言或行为中找到一个漏洞或关键词作为切入点，发出带有调侃意味的感慨或疑问。普通话里相当于相声的“捧哏”。
那么为什么要谈的是测试如何提交有效缺陷却说到“吐槽”去了呢，二者之间是否有什么联系呢？大家不妨先思考一下，下面进入正题：
大家对吐槽都不陌生，可以说每天都在吐槽，而大家每天吐槽的点基本上都差不多。比如：为什么我找不到功能测试的好工作呢；为什么我在公司里不被重视呢；为什么我提交的缺陷开发总是不乐意改呢，等等。其实这些吐槽都是比较表面的，没什么作用的吐槽，更像是一种抱怨和茫然。
不知道大家做测试的时候有没有遇到一个现象：
当你提出一个问题，开发会不认可你，或者客户也不认可你。
你就会说公司软件bug那么多，大家又不接受我提交的缺陷，那我有什么办法。
最后结论是：这公司不适合我，我的工作不受重视。
但是大家更深层次的想过问题的根源吗：
1、你提交的bug到底是不是bug？
2、开发为什么要为你提出的问题去花时间去改？
所以最重要的问题就是：当你提交bug给开发，让开发去改的时候，如果你不能让他信服，人家凭什么配合你去改这个BUG？
所以说回来我们日常的吐槽，每个人都会吐槽，但是并不是每个人都能吐槽到正确的点上。
其实很多事情都是存在争议的，并没有绝对的对与错，看待一个问题更多的是站在不同的角度和环境下能得出不同的结论。
那么在这么一个前提下，我们测试工程师的工作就显得比较富有意义了，因为软件测试是一种过程，在这个过程中，你需要做的就是找出缺陷，让开发改掉它，并得出软件质量能达到预期的最终结论（也就是上线）。
而且不管你现在做的功能测试，还是将来要做的接口、自动化、性能等等，你要考虑的首要问题都是如何提交bug以及让开发人员能心甘情愿的改掉这个bug，最牛逼的就是你提出一个bug，开发不但不反感还觉得你提的bug避免了未来可能会出现的事故。一个好的测试工程师总能做到这点，而且他总是团队里面的“润滑剂”，协调好开发、产品、运维之间的关系，贯穿于软件质量生命周期的全过程。
是否能有效地提交缺陷始终是界定一个测试人员的标准，而测试人员掌握代码知识也是为了更好地进行有效缺陷地提交。了解一下测试大师们是如何优雅地提交bug，在团队中混得如鱼得水，加群记得备注（缺陷），希望大家可以一起交流进步。
下面帮大家梳理一下从有效吐槽到有效缺陷的转变过程：
一，我们为何要吐槽（提缺陷）？
我们吐槽可能有很多原因，基本上可以总结为下面三点：
主观意识的提升
首先你会意识到与自己有关，与我无关的事情没人会去吐槽，或者说根本不知道要怎么吐槽好。突然想到这也可能会是一个尬聊的原因，如果你根本不了解一个人，他和你的槽点都不一样的话，两个人一定是没话说的。
其次意识到自己的责任和义务，比如在测试人员在公司上班的时候，就算你不想吐槽，为了工作的正常进行，你也不得不吐槽（提缺陷）。
为了工作环境的和谐
人人都是有自己的思想的，不可能大家不进行交流也能把工作做好，大家都需要把自己的想法说出来，表明自己工作中需要得到的帮助和协调，然后再一起努力并最终完成工作。
证明与表达自己
基本上每个人都预测过某些事情，比如他如果不这么做，就会怎么怎么样。通过自己的得到的信息资源的整合，做出一个预测其实也是一种知识的体现。
二、如何进行有效吐槽（提缺陷）
吐槽要吐到点上
内容准确：作为一个测试工程师需要保证提交的缺陷内容上是准确的，如果开发看到都不知道你写的缺陷是什么那怎么修改。
结果清晰：要把缺陷的结果清晰的描述出来，更加方便开发知道哪里出错，定位缺陷做出修改。不要只考虑自己工作的完成，开发花时间定位bug浪费的是大家的时间。
符合逻辑：提交缺陷的时候一定是要符合逻辑的，问题的出现总是有前因后果，不可能因为我努力学习所以他考上了大学。
吐槽要引起共鸣
代表大多数人的想法：要为自己的观点树立坚实的群众基础，如果大家都认为你是对的，工作就能很轻松的进行下去。但是不是你找出一个缺陷它就一定是一个缺陷。
制造不同观点的讨论：也可以提出不同观点让大家来讨论，特别是你自己都不确定是否是缺陷的时候，提前发现总比被开发怼回来强。
三、吐槽和缺陷
吐槽的主要原因是每个人看待问题的方式和维度不同，它一般是基于支持的体系、你的大局观，你的利益。举个栗子，我是火箭的球迷那我肯定是要为火箭说话的，吐槽的点都是裁判判罚的是否对火箭有利。这是基于一个球迷的角度。
缺陷和吐槽要有一致性。缺陷的提出总是基于公司的利益，为了让公司的软件质量更高你需要提缺陷。那么基于软件技术提缺陷你能否做到测试左移？你能在系统测试级别还是在集成测试级别还是在单元测试级别甚至在需求级别就能找到缺陷？基于用户需求提出缺陷成本是很低的，但这需要你不断的思考。
比如说钉钉，钉钉有个功能是已读回执，老板发了一条信息，只要你点开了老板就知道你已经读取了这条信息，这会给你压力，让你尽快回复老板的信息。你可能觉得这个功能很烂，给你造成了压迫感。但是从整个使用环境来说这能有效地提升工作效率，增强公司上下沟通能力。
很多设计都是基于吐槽而来的，比如产品需求分析的时候，有人吐槽说以后使用的人变多了怎么办？那么这就是一个有效的吐槽，开发人员会根据将发生的情况做出合理的设计避免负载严重。
四、有效缺陷
有的缺陷提的太表面，比如字体大小不一致，选择框一个上一个下。很多时候我们提缺陷的时候，业务不够精通不能站在用户的角度去说服开发的时候，那么这时候你需要的就是考虑用技术。所以说现在做测试为什么越来越需要开发的能力，你需要懂得调试的功能，只有这样你才能明白这是底层的问题还是表面的问题。
比如点击提交失败，开发一般是不乐意改这样的bug的，因为你的缺陷不够有效，不能结合相关的数据定位到问题的所在。开发要花很多时间帮你排查这到底是业务问题还是底层问题。所以为什么功能测试真的很轻松，因为这都是别人花了大量的时间帮你把本来属于你的工作任务完成掉了。可能你不会认同我的观点，但事实就是这样，开发和测试和运维的界限不是那么明显。
当开发觉得他可以自测试，自验证的时候他就可以把你干掉了，因为你根本没有什么存在的价值。而所谓的开发不能测试自己的程序，他只要把程序再给其他开发再测一遍就行了。
因此测试人员在devops团队的时候，通常都会有一种感觉，就是自己的存在价值太低了。在整个团队进行快速迭代敏捷开发的时候本身留给测试的时间就不多了，如果你不能快速，准确定位问题并提交。在一周迭代一次的版本中，那确实没什么存在必要。
那么，作为软件测试工程师的你，将会如何选择未来的路？