Dry Goods-Senior Test engineer How to submit effective defect _ Software test

In order to facilitate understanding, before beginning to talk about how to submit the issue of effective defects, we would like to talk about the "spit" point of view.

The word "spit" means to find a loophole or keyword in the other's language or behavior as the cut-in point, and send out the emotion or question with the meaning of ridicule. Mandarin is equivalent to the "捧哏" of crosstalk.

So why are we talking about testing how to submit an effective defect but talking about "spit" going, and whether there is any connection between the two? You may wish to think first, the following to get to the point:

We are not unfamiliar with the spit, you can say every day in the slot, and everyone spit every day the point is basically the same. For example: Why I can't find a good job of functional testing, why I am not valued in the company, why I submitted the defect development is always unwilling to change, and so on. In fact, these spits are relatively superficial, no effect of the spit, more like a kind of complaining and dazed.

Do not know when you do test when there is a phenomenon encountered:

When you ask a question, development will not recognize you, or the client will not recognize you.

You will say that the company software bugs so many people do not accept my submission of defects, then I have any way.

The final conclusion: this company is not suitable for me, my work is not appreciated.

But do you think more deeply about the root of the problem:

1, the bug you submitted is not a bug.

2. Why do you need to take the time to change the questions you ask?

So the most important question is: when you submit a bug to the development, let the development to change, if you can not convince him, people who cooperate with you to change the bug.

So back in our daily spit, everyone would spit, but not everyone could spit on the right spot.

In fact, many things are controversial, and there is no absolute right and wrong, look at a problem more is standing in different angles and circumstances can draw different conclusions.

Then in such a premise, we test engineer's work is more meaningful, because software testing is a process, in this process, you need to do is to find the defect, let development to change it, and get the software quality to achieve the expected final conclusion (that is, on-line).

And regardless of what you're doing now, the interface, the automation, the performance, and so on, the first thing you need to think about is how to submit bugs and let developers be willing to get rid of the bug, and the best thing you can do is ask a bug, Development is not only objectionable, but also feel that the bug you mentioned avoids future accidents. A good test engineer always does 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 lifecycle.

The ability to effectively submit a defect is always a standard for a tester, and the tester's knowledge of the code is designed to better deliver the defect. Understand how the test masters are graceful to submit bugs, mix well in the team, add Group remember notes (defects), I hope you can communicate progress.

Here's a way to comb through the transition from effective spit to effective defect: one, why do we have to spit out the groove (defect).

There may be a number of reasons why we spit, which can basically be summed up in the following three points: Elevation of subjective awareness

First of all, you realize that you have something to do with yourself, that no one is going to spit, or that you don't know how to spit. Suddenly think that this may also be a reason for a race chat, if you do not know a person, he and your slot point is not the same, two people must have nothing to say.

Second, be aware of your responsibilities and obligations, such as when testers work in the company, even if you do not want to spit, in order to work properly, you have to spit (defect). For the harmony of the working environment

Everyone has their own ideas, it is impossible that people do not communicate can also do a good job, everyone needs to put their own ideas to say that they need to work in the Help and coordination, and then work together and finally finish the work. Prove and express yourself

Basically everyone has predicted something, such as what he would do if he didn't. Through the integration of their own information resources, to make a prediction is actually a knowledge of the embodiment. Second, how to carry out effective spit groove (defect) spit to spit point content accurate: as a test engineer to ensure that the content of the defect submitted is accurate, if the development see do not know what you write the flaw is what that how to modify. The results are clear: to describe the results of the defect clearly, it is more convenient to develop and know where to go wrong, positioning defects to make changes. Do not only consider the completion of their work, development spend time locating bugs waste is everyone's time. Logic: The submission of defects must be logical, the emergence of problems always have a cause and result, it is impossible because I study hard so he admitted to the university. The spit is going to resonate. The idea of most people is to build a solid mass base for their own ideas, and if everyone thinks you're right, work can go on very easily. But instead of finding a flaw, it must be a flaw. Create a discussion of different points of view: You can also put forward different points of view for everyone to discuss, especially if you are not sure whether it is a defect, early discovery is always better than being developed frontline back strong. Iii. slot and defect

The main reason for the spit is that everyone looks at the problem in different ways and dimensions, it is generally based on the support system, your general view, your interests. Give me a chestnut, I'm a rocket fan. I must have spoken for the Rockets, and the point of the spit was whether the referee was good for the Rockets. This is based on the angle of a fan.

Defects and grooves should be consistent. Defects are always based on the interests of the company, in order to make the company's software quality higher you need to ask a flaw. So based on software technology to ask the defect you can do to test the left shift. You can find defects at the system Test level or at the integration Test level or at the unit Test level and even at the demand level. The cost of presenting a defect based on user demand is low, but it requires constant thinking.

For example nails, nails have a function is read receipts, the boss sent a message, as long as you open the Boss will know that you have read this message, it will give you the pressure, so that you quickly reply to the boss's information. You may feel that this function sucks and creates a sense of oppression. But from the overall use of the environment this can effectively improve work efficiency, enhance the company's ability to communicate up and down.

Many of the design is based on the spit, such as product demand analysis, some people spit out the use of people later how to do. So this is an effective spit, and developers will be able to make a reasonable design to avoid heavy loads based on what happens. Iv. Effective deficiencies

Some defects are raised on the surface, such as the font size is inconsistent, select the box one last. A lot of times when we ask flaws, the business is not proficient in the user's point of view to convince the development of the time, then you need to consider the technology. So now do test why more and more need to develop the ability, you need to understand the function of debugging, only then you can understand this is the bottom of the problem or the surface of the problem.

For example, click to submit a failure, development is generally not willing to change such a bug, because your defect is not effective, can not be combined with relevant data to locate the problem. Development takes a lot of time to help you find out whether this is a business problem or an underlying problem. So why is the functional testing really easy, because it's someone else who spends a lot of time helping you get the job done that belongs to you? You may not agree with me, but the truth is that the boundaries between development and testing and operational dimensions are not so obvious.

When development thinks he can test himself, he can kill you because you have no value at all. And the so-called development can not test their own programs, he just put the program to another development to test again on the line.

As a result, testers often have a feeling that their presence is too low in the DevOps team. There is not much time left for testing when the entire team is fast iterative agile development, if you can't quickly and accurately locate the problem and submit it. In one iteration of the week, that's really not necessary.

Then, as a software testing engineer, you will choose the way forward.

More Test experience + Test quiz, can add QQ group test to the great God we progress together ~