In order to facilitate everyone's understanding, before I start talking about how to submit valid defects, I would like to share with you my point of view on "Tucao".
The word "Tucao" refers to finding a loophole or key word in the other party's language or behavior as an entry point, and sending out a mocking emotion or question. In Mandarin, it is equivalent to "holding 叏" in cross talk.
So why do we talk about how to submit valid defects in the test but talk about "spit out"? Is there any connection between the two? Let's think about it first, let's get to the point:
Everyone is no stranger to Tucao. It can be said that they are complaining every day, and the points that everyone complains about every day are basically the same. For example: why can't I find a good job in functional testing; why am I not valued in the company; why the bugs I submit are always reluctant to fix, etc. In fact, these complaints are relatively superficial, useless complaints, more like complaints and daze.
I don't know if you have encountered a phenomenon when you do the test:
When you ask a question, the developer doesn't approve of you, or the client doesn't approve of you.
You will say that there are so many bugs in the company's software, and everyone does not accept the defects I submit, then what can I do.
The final conclusion is: this company is not for me, and my work is not valued.
But have you thought about the root cause of the problem more deeply:
1. Is the bug you submitted a bug?
2. Why should developers take the time to fix the problem you raised?
So the most important question is: when you submit a bug to the developer and ask the developer to fix it, if you can't convince him, why should others cooperate with you to fix the bug?
So back to our daily complaints, everyone will complain, but not everyone can complain to the right point.
In fact, many things are controversial, and there is no absolute right or wrong. Looking at an issue is more about drawing different conclusions from different angles and circumstances.
Then under such a premise, the work of our test engineers is more meaningful, because software testing is a process. In this process, all you need to do is to find out the defects, let the development correct them, and come to the conclusion The software quality can reach the expected final conclusion (that is, go live).
And no matter what functional testing you are doing now, or the interface, automation, performance, etc. that you will do in the future, the first thing you need to consider is how to submit bugs and let developers change the bugs willingly. The most awesome thing is You raise a bug, and the developer not only doesn't dislike it, but also feels that the bug you raise avoids possible future accidents. A good test engineer can always do this, and he is always the "lubricant" in the team, coordinating the relationship between development, product, operation and maintenance, throughout the whole process of the software quality life cycle.
Whether the defect can be effectively submitted is always the standard that defines a tester, and the tester's knowledge of the code is also in order to better submit the defect effectively. Learn how the test masters submit bugs gracefully, and they get along well in the team. Remember to remarks (defects) in the group. I hope everyone can communicate and progress together.
Let’s help you sort out the transformation process from effective complaints to effective defects:
One, why do we complain (defects)?
There may be many reasons for our complaints, which can be basically summarized into the following three points:
- The improvement of subjective consciousness
First of all, you will realize that it is about yourself, and no one will complain about things that have nothing to do with me, or you don’t know how to complain at all. It suddenly occurred to me that this might also be the reason for an awkward chat. If you don't know a person at all, and his slot points are different from yours, the two of them must have nothing to say.
Secondly, be aware of your responsibilities and obligations. For example, when testers are working in the company, even if you don’t want to complain, you have to complain (defects) in order to work normally.
- For the harmony of the working environment
Everyone has their own ideas. It is impossible for everyone to do a good job without communicating. Everyone needs to express their own ideas, show the help and coordination they need in their work, and then work together to achieve the ultimate goal. Get the job done.
- prove and express yourself
Basically everyone predicted something, like what would happen if he didn't do it. Through the integration of information resources obtained by oneself, making a prediction is actually a manifestation of knowledge.
2. How to make effective complaints (defects)
- Tucao to spit to the point
- Accurate content : As a test engineer, you need to ensure that the submitted defect content is accurate. If the developer does not know what the defect you wrote is, how to modify it.
- 结果清晰：要把缺陷的结果清晰的描述出来，更加方便开发知道哪里出错，定位缺陷做出修改。不要只考虑自己工作的完成，开发花时间定位bug浪费的是大家的时间。
- 符合逻辑：提交缺陷的时候一定是要符合逻辑的，问题的出现总是有前因后果，不可能因为我努力学习所以他考上了大学。
- 吐槽要引起共鸣
- 代表大多数人的想法：要为自己的观点树立坚实的群众基础，如果大家都认为你是对的，工作就能很轻松的进行下去。但是不是你找出一个缺陷它就一定是一个缺陷。
- 制造不同观点的讨论：也可以提出不同观点让大家来讨论，特别是你自己都不确定是否是缺陷的时候，提前发现总比被开发怼回来强。
三、吐槽和缺陷
吐槽的主要原因是每个人看待问题的方式和维度不同，它一般是基于支持的体系、你的大局观，你的利益。举个栗子，我是火箭的球迷那我肯定是要为火箭说话的，吐槽的点都是裁判判罚的是否对火箭有利。这是基于一个球迷的角度。
缺陷和吐槽要有一致性。缺陷的提出总是基于公司的利益，为了让公司的软件质量更高你需要提缺陷。那么基于软件技术提缺陷你能否做到测试左移？你能在系统测试级别还是在集成测试级别还是在单元测试级别甚至在需求级别就能找到缺陷？基于用户需求提出缺陷成本是很低的，但这需要你不断的思考。
比如说钉钉，钉钉有个功能是已读回执，老板发了一条信息，只要你点开了老板就知道你已经读取了这条信息，这会给你压力，让你尽快回复老板的信息。你可能觉得这个功能很烂，给你造成了压迫感。但是从整个使用环境来说这能有效地提升工作效率，增强公司上下沟通能力。
Many designs are based on complaints. For example, when analyzing product requirements, some people complain that more people will use it in the future. What should I do? Then this is an effective rant, and developers will make a reasonable design based on what will happen to avoid serious load.
4. Effective Defects
Some defects are too superficial, such as inconsistent font sizes, and the selection boxes are one up and one down. Many times when we mention defects, when the business is not proficient enough to persuade the development from the user's point of view, then what you need at this time is to consider the use of technology. So why is it more and more necessary to develop the ability to do testing now, you need to understand the function of debugging, only in this way can you understand whether it is an underlying problem or a superficial problem.
For example, if the click to submit fails, developers are generally not willing to change such bugs, because your defects are not effective enough to locate the problem in combination with relevant data. Development takes a lot of time to help you troubleshoot whether this is a business problem or an underlying problem. So why is functional testing really easy, because other people spend a lot of time helping you complete the work tasks that belonged to you. You may not agree with me, but the truth is, the line between dev and test and ops is not so clear.
When the developer feels that he can test and verify himself, he can kill you, because you have no value at all. The so-called developer cannot test his own program, he only needs to test the program again for other developers.
Therefore, when testers are in the devops team, they usually have a feeling that their existence value is too low. When the entire team performs rapid iterative agile development, there is not much time left for testing. If you can't quickly locate the problem and submit it. In a weekly iteration, that really isn't necessary.
So, as a software test engineer, how will you choose the future path?
For more test experience + test questions and answers, you can add QQ group test entry to the great god, 
we will make progress together~