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

Today I want to talk about the relationship between testers and testing tools.

Since I started contact testing in 2002, I have used numerous testing tools. The testing tools needed by the communications industry are much more complex than those of the Internet, because of the need to simulate the various problems encountered in communication. Test tools can customize all kinds of messages, various network environments, and all kinds of exceptions. Generally very professional testing tools need to be purchased, and the price is not cheap. Based on automated regression, Nosey has done robot to allow testers to write test cases in a tabular way. The time spent on manual testing and automated testing is about 1:5 to 1:10 (detailed in "Human parts"). Automatic regression found very few bug, and no one will count this number. I believe that unless manual testing is disabled, automated regression will always find very little bug. While automation coverage has increased significantly, so has the number of customer pronto. But I don't know if there's a connection. It's worth analyzing.

When it comes to Internet companies, testing tools are much simpler and are basically used for automated regression. The management of TC is not as complex as the communications industry, and there is no need to associate use cases with requirements, nor does it need to count the coverage of use cases to requirements.

Internet companies like to write their own test frameworks, which is understandable because the functions are relatively popular and simple. Just use an open source framework. Writing your own framework can improve the response speed, and any personalized needs can be quickly met, which is good, and it is also a training opportunity for testers to write code.

But tools are just tools, and testers can use tools to improve the efficiency of testing. A more important job for testers is to find bug. I use tools when I need them, and I don't need them at all when I don't need them.

I'm sure everyone understands such a simple truth.

However, it seems that many people do not understand this truth now.

First of all, let's talk about why we use tools. There is a saying that sharpening the knife does not miss the firewood cutter. The purpose of sharpening the knife is to improve the efficiency of chopping firewood. Right? So, is it better to sharpen the knife or cut wood? No one care, everyone only care whether the firewood is cut well, whether it is fast, whether it is much. If you only cut wood without sharpening the knife, the wood will be cut slowly. If you only sharpen the knife and don't cut firewood, it will be even worse. There will be no firewood.

I would think that a good woodcutter will certainly attach importance to sharpening the knife, but after sharpening the knife, he will cut firewood, which can be chopped for several days at a time. A good tester will certainly find ways to improve his productivity, make good use of tools, and create tools when there are no tools, but he will still focus on testing.

A good manager will care about whether the firewood is cut well in the end, rather than whether this person can sharpen the knife. It doesn't matter whether you can sharpen the knife or not. what matters is whether you need to sharpen the knife, only when you need to sharpen the knife, and you don't have to sharpen the knife when you need it, and you are not a good woodcutter. Isn't that right?

The relationship between testers and testing tools should be the relationship between being used and being used. A good tester pays more attention to whether his testing work can be done efficiently. Do as much as you can do your work better. There is no need to make any tools for others to use, to make a framework, to be influential. When considering KPI, it makes no sense to see how many tools the tester has made for others to use when judging a promotion.

I don't want to see testers being burdened by tools, nor do I want tools to be the standard for considering a tester. A tester's good development skills need not be reflected in making a test framework and testing tools, but in rejecting a useless product during a requirements review and blocking a stupid design during a technical review. I remember a boss once said that testers know more about business than developers and know more about technology than business. I think this sentence is very reliable, and that's what I did. I also often make tools, just to improve efficiency, but not for that purpose. It has been said that a good programmer needs three precious qualities: laziness, impatience and pride. Laziness is the dislike of repetitive work, which is replaced by automation, impatience is impatience to do complex and tedious things, and pride is the belief that you can make the best products. In fact, the testers are the same. A good tester will use smart ways to solve his own problems, will sum up experiences and lessons in the problems, and will leave his own figure in successful products.

So, when testers are scrambling to make tools, I feel very at a loss. What's going on here? Is it so fulfilling to build a daily tool for dozens or hundreds of people based on an open source framework? Is it so easy to be recognized? Is it less attractive to work with PD and developers to make an excellent product used by millions or hundreds of millions of people? Isn't it more challenging and meaningful for buyers and sellers to agree that your product can get services from your product, get orders, and change the status quo than a test framework that manages bug and use cases and automated regression on a daily basis?

If you look at each role from a company's point of view, a good product manager needs to control the positioning of the product and design a product that meets the operational needs, and a good development needs to use his own technical ability to quickly develop a stable and easy-to-use product. Good testing requires the use of their own testing techniques and experience to identify all problems and correct them as soon as possible. The purpose of development is to help product managers choose the best technology to implement the product. Testing moves forward to help product managers and developers avoid mistakes and minimize the cost of mistakes. Every role has its own value, and every role is very important. Developers need to be proficient in their own technology, to achieve the best in the field of technology, testing needs to understand the products and technologies in each field, in every link "say no". Sometimes I even think that doing a good test is more difficult than a good developer.

However, this is not the case. People always think that creating a product is very fulfilling, and to tell you the truth, I often think so. Testing is mentioned only when a product is scolded, and people will say, how did this product pass the test? it sucks! But when a product is excellent, no one will say, the test of this product is too good, the product is so good! This is the most painful part of taking a test. Many colleagues have asked me the same question, how can I show a good test? I remember when I first came to the Internet company, a developer asked me: there are more than 100 lines of code here, can you understand it? I really didn't know what to say. It's like once a courier asked my mother, can you write? My mother wanted to tell him at that time, I graduated from Tsinghua University, do you think I can write? Later, when I thought about it, I didn't bother to say it, so I said I could write. Sometimes I wonder what I would be if I hadn't gone to Nokia for testing and stayed at VIA for development. At least one day, a developer will ask me if you can read the code. Perhaps it is out of this mentality that testers are enthusiastic about making tools, going to wireless nights and horse racing. Is to prove that I am not incompetent, I do not understand the code, I just chose to test this position! But there is no need to prove it in the first place!

I remember when I was in the interview, the technical director asked me, what is your position for yourself? I said, it's the test architecture. Because I have experienced every step in V Model, I know how to control a product. I will also lead all the testers forward, want to go back, and control the quality of the products.

But now, testers are constantly using testing tools to prove their value and ability, and the company is also using development capabilities to measure a tester, which makes me feel too much. How does the tester feel about such a measure? Testing tools are no longer tools, but my value. The tools are here, so I am. I am a high P, so I make tools. The purpose of sharpening the knife is no longer to cut wood, but to exist. Isn't that ridiculous?

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.