Some people say that software development can easily be transferred to software testing, but it is somewhat difficult to transfer software testing to software development. Is this really the case? In fact, in the IT industry, there is such an invisible and unexplainable chain of contempt. Those who do development don't look down on those who do testing, and those who do testing are afraid of offending those who do development. Sometimes the tester not only cannot become a prominent position for the entire team, but will be restricted by various things. If development is a test of IQ, then the test is more about the integration of IQ and EQ. In a team, development and testing are both important. The so-called incomparable, but some people in the industry just to highlight their own difference.
Many programmers like to use architecture to describe programs, and testing exists to ensure the quality of software and meet user needs. So why do programmers who are willing to compare software with architecture think that software does not require testers? This idea is obviously Very ridiculous.
What does the test do? What does the test do, can programmers do it easily?
1. Monitor the product process. From the perspective of time control, there is a balance between developing new features and fixing bugs. Developing too fast may deliver a more problematic version to the next stage, making subsequent problems more difficult to deal with. How do we know how the software quality is at each stage? There are many specific methods, such as regression testing, code coverage, stress testing, and so on. But who will collect and analyze this information, and how? What kind of conclusions can be drawn? How many programmers will do this by themselves?
2. Build complex application scenarios. Who knows how many domain controllers are needed to test a complete Active Directory server regression test environment? The record I built is 11, not including the clients that may be dynamically added and deleted in the middle. It contains a lot of deliberate destructive operations. After each destruction, the site must be restored for the next test. How many programmers have constructed such a scene?
3. Simplify problem reports. When a user report occurs, the steps they initially give are often too simplified or too cumbersome, and lack a step description that directly points to the problem. In many cases, because the steps are not clear, there are many detours in the analysis process. At this time, there needs to be someone to constantly deal with customers and locate key steps. This step must always be completed, so who will handle it? How many developers are really responsible for handling these?
The skills required for testing and development overlap, but they are basically two positions with different requirements. Failure to develop technology for testing does not mean that you can become a good tester. Testers are really not as easy to replace as programmers think. Although testers have lower requirements for coding skills, it does not mean that developers can automatically become a qualified test.
Testing this position has testing ability requirements. The main difference between it and development lies in the ability of analysis and statistics. The basic ability of testing is to be able to execute the test strictly according to the steps, which is really easy to get started. But a good test requires more than just this. When a person reaches a certain level in the test, he/she must begin to pay attention to many process analysis tasks.
In fact, development is the same in this position. At the beginning, it was not difficult to write an algorithm such as sorting. But a good development is not just enough. When entering the industry for a long time, development must start to pay attention to domain knowledge (such as the Adaptive Wide Angle filter recently released by Dongge), architecture, design (such as interoperability, Microsoft has been scolded for many years), etc. . These things have nothing to do with coding itself, but to become a good development must master these. These two positions may have similar competence requirements at the beginning, but the difference will become greater over time. But this is not a reason for the development department to despise the testing department.
On the other hand, it is precisely because of the difference between the two positions that there is a difference in hobbies. Some people didn't understand the position of the test at first, and gradually became more and more like it; after some people tried it, they still felt that it did not suit their interests, so they chose to leave. This is all normal. People have their own ambitions, and this thing barely comes.
The test entry threshold is relatively low, but after entry, if you want to get a lot of development, the ability requirements even exceed the development. As I said before, an excellent tester, in addition to basic testing skills, also has to type some code and understand some programs. If you wait for a tester to grow up to be able to test and type code, that's when a programmer who only knows how to type code should be anxious and anxious. Don't look down on anyone!
New dream summary: Testing is not a trash can for development. If a harmonious team wants to do a good job of a product, there should not be some "contempt" or "superiority" mentality.