Career prospects for Software Testing

The article I saw from Yan Hui's blog: http://blog.csdn.net/superyan/archive/2006/05/22/748921.aspx. In fact, my comments are very simple: do not perform tests instead of being a Chinese dragon. Ordinary people have no prospects for testing. The reason is also very simple. Let's take a quiz: 10 seconds. Come on! Name your ten idols. Is there anything in it that relies on testing? Is the requirement too high? Well, I will give you 10 blogs you read most often. Are there any tests? Two of my blogs are dedicated for testing. Unfortunately, their articles are related to development. In other words. Their major is not a test. They are programmers and their business areas are testing. But we will discuss this topic later. Is this quiz of no universal significance? Well, let me give another example of a leading company in the industry. The company has about 50 academicians. Guess how many tests are involved? Let me tell you: 1. This is also a special case. The academician is responsible for system testing of a large operating system. He knows the system to the point where the customer calls the system for every visit. Therefore, this example proves that you should not perform tests easily. The following are Academician distinguished engineer (DE) and describe senior technical staff member (STSM ). There are 10 STSM and four or five de in the R & D lab of 2000 people in the company. How many of them are test origins? The answer is 0. STSM is senior developer (SE ). The lab has more than two hundred employees in a department, with nearly Testers in the testing department. What are the number of non-manager se? The answer is still 0! Let's look at another data. The number of patents for the Testing Division of that Department in the past three years does not add up to a group with more patents for one year. We don't need to mention the quality. We also need to know that this company has attached great importance to testing. Both their tester salaries and titles are of the same level as those of developers. The company has a dedicated testing department. The testing department has a sufficient budget. There are strict procedures for testing. Every year, the company has a wide range of rewards for testers. Policies inside and outside the company promote the future of testers. Testers and developers are equally important. But what then? By doing the same technology, the chances of improving testing are much smaller than those of development. How do you compare with others? Fewer articles are published, fewer patents are obtained, fewer opportunities to show up, and fewer opportunities to discuss product planning and design! Reality: If ordinary people are interested in technology, testing is a dead end.

Most people perform black box tests. The project is tight, and most of the work time is spent on monotonous and repetitive mouse clicks. Managers do not think that your work is difficult. Since there is no difficulty, why should we commend you for your work? Yes, the test is still challenging. The problem is that after you finish your workAdditionalOnly when you have the opportunity to do the "challenging jobs ". In the past, when I was in the testing department, the opportunity for everyone to be promoted came from the completion of the so-called "Extension Project ". Isn't that ironic? It is your duty to finish the test at hand. To be commended? Create a project unrelated to the test! The tester who got the highest rating in my testing department at the end of the year didn't perform the test at all. He is responsible for developing our automation framework. You can imagine the blow to our morale: If you want to earn performance, don't test it! In the next year, testers will not hesitate to delay the test to seize the "Extension Project". I don't need to say that everyone can guess it?

Some people may say that it is not easy to find hidden errors. It also requires talent and efforts. Very correct! Unfortunately, managers do not understand. They cannot measure your performance either. Program errors are missing, which is a good developer. There are not many errors after the software is released. You should do it. There are a lot of errors after the software is released. What do you do? In other words, no one knows how much you actually paid for an error. No one cares about the importance of a mistake. This is also normal: When an error is found, it is no longer mysterious. It is assumed that this error is easily discovered. Since it is easy to be discovered, what does your tester do?

It is not easy to keep the technical progress during testing. Experts are repeatedly honed in the Process of conquering challenges and learning lessons. When you drop your youth over and over again with the left mouse button, your colleagues are worrying about an algorithm problem and are discussing a design question. When your sweat drops on the same test document, your colleagues are deciding on a new technical specifications. In the long run, who will stand on the leading technology line? The biggest lie I heard when I was a tester was that "programmers only know the implementation of a specific module, while testers have a big picture when dealing with multiple modules ". Lie, a lie! Once you are a programmer, you will know what testers know. They don't know. You also need to know. Since programmers can learn more, why should they be testers?

Don't think I'm not looking down on testing. On the contrary, I think testing is crucial to the success or failure of software. I just want to say that few companies now offer the right treatment to testers. Measuring the tester's work is more difficult than measuring the programmer's work (probably this is why the tester in startup is more promising, because their performance is relatively easy to evaluate fairly ). Many excellent testers do not have a bright future. They leave the testing department and even change their careers. Only companies suffer losses.

Writing down this small feeling is also to commemorate the ups and downs of my testing year and a half.