Shulou(Shulou.com)06/03 Report--

I chatted with a new friend the other day.

"are you a programmer?"

I am so angry, do I look like this? Is it like it? I really want to slap him.

"No, I do software testing. I don't use that much code, so I can't call it".

"Oh! so you specialize in finding fault, aren't you?"

At that time, I decided that this friend had said goodbye to you.

"I'm a tester. I'm looking for defects, not troubles. Thank you for being old. Be busy first. Goodbye."

When I get home, I want to share:

First:

The test is to find bug, not to find fault. In the past, when I was outsourced to do testing, I was faced with PM, the so-called customer was the developer, and because I was far away from the developers, I basically used email to communicate, so I didn't feel too much at that time. I just did my job, found more problems as much as possible, made the problems I found more valuable, and made the problems I found reproduce 100% as much as possible! Now I have entered a company that makes its own products, and the people I face have all changed. I used to think that I was facing development, but now I understand that in the company that makes my own products, I have to face not only development, but also products, designs, and customers who really use them! In the past, I always heard that testing and development are sworn enemies, it is difficult to communicate, and I have seen a lot of questions about the communication between development and testing. In fact, there is really nothing wrong with it, because everyone's ultimate goal is the same. All in order to do the project well, the test hopes that the project is good, and the development hopes that it will succeed! For example, I read an article two days ago that developers actually value the quality of products as much as testing, because they are people who really implement them, and who doesn't want what they do to be as perfect as possible? And why is there a gap between development and testing? Is it because the developer wants the test to identify the critical and deadly bug in the first place, and as the test itself? Every problem you see will be reported in time, but the developer will not look at these so-called priorities, so you will think that if you are not looking for a major bug, you will find fault with it. In fact, each role will be considerate and solved. Since the goal is the same, why do you have to struggle with this priority? When developing, don't think that the testers are deliberately finding fault. The questions they ask should be flaws, and you can just decide on your own priorities. And testing, do not think that developers have a problem with themselves, in the submission of bug, it is best to first pick those major bug, vibration development, and then report those less important issues together, so that not only the value of testing is reflected, and the development will take a fresh look at you, while greatly improving the status of testing! Always remember that our test is looking for bug, not fault!

Second:

Testing is only to improve the quality of the product, not to ensure the quality of the product. I remember the first time I came into contact with testing, in class, my mentor said to me, "our testing is to improve quality, not to ensure quality." And there are a lot of people who don't know much about testing will have a misunderstanding, why do they think they want to test? Since we have spent money on you, we should make sure that our products are free from defects. For such a person, I can only say that it is not very rational, not because I shirk my responsibility as a tester, but because there is no 100% thing in the world itself. what we can do is to try our best to improve, find out the most problems and solve them accordingly. Testing is not omnipotent. If someone says that I test to ensure the quality of your products, then I can only say that you have been tricked. We just improve the product quality, not guarantee the product quality!

Third:

Testing requires the participation of all people, not just a matter for test engineers. Some people think that there are testers anyway, so they don't care much about the product. in fact, testing is everyone's business, including customers, because no matter how meticulous a person is, there are no countless pairs of eyes to see comprehensively. Forget that the boss of which company has always advocated the testing consciousness of the whole people, I think it is very good, because every employee is a member, and every product is not only the image of the company, but also the embodiment of each of us. It's just that our division of labor is different, but it all represents us, and I think such a management concept can also have the power to unite people. Can let everyone do things better together! Instead of relying solely on testing and finally making people lazier and lazier, I find that today's companies have this phenomenon, developers sometimes have a dependent mentality that there is testing anyway? For their own program is not so serious, and their own finished is not very serious inspection, took the program, casually grabbed is bug. The final development headache, testing is also a headache, so the company should fundamentally stimulate this awareness, testing is not only a matter for test engineers, but also an important thing that requires the participation of the whole people!

The above is my little thought, which may be a little broken or biased, just for your reference, but I still hope to change the minds of some people.

I also have some information about software testing here, about getting started. If necessary, please comment and leave a message. I will send the network disk address in the comments.

If you think you are familiar with the content of the article, please comment and like it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.