Importance of training testers

Original works can be reprinted. During reprinting, you must mark the original source, author information, and this statement in hyperlink form. Otherwise, legal liability will be held. Http://debbie.blog.51cto.com/2754849/503195

 

Whether it's the company's leaders or testers themselves, there is a common misconception that testing is simpler than development, faster on hand, and less demanding on technology and experience. Many companies offer lower salaries for testers than developers, and there is no broader career path for developers. Testers often think that testing is about to break commands, take logs, and hand over all the difficulties to developers. They do not think they are responsible for improving the quality of software, the requirements for yourself are also very low. Some of my colleagues believe that developers and architects can intervene in and question the test process, but testers should not intervene in or question the design and demand analysis of the software, the tester should just perform the test. In fact, such an idea is very unfavorable to the enterprise's own development. The quality of a product depends on the weakest link in the product chain. Design, development, and testing are equivalent. The design is strong and the test is weak, so the product quality is the same. The software cannot be error-free. I remember reading a book before, and someone who used to develop hardware was later transferred to software. There is no error in the Code he wrote. Everyone is wondering how he did it. He asked everyone more strangely, ah? Can errors occur? He originally made hardware and hardware was hard to tolerate bugs. Therefore, he was required to be careful and strictly controlled. However, software is different. software bugs seem to be inherent for many reasons. Software applications are developing rapidly and upgrading quickly. The software structure is complex, with rich layers and numerous interfaces. Software developers have a low threshold and varying quality. People have a high degree of tolerance for software bugs, and so on. We cannot expect zero Software defects. Although agile advocates once declared that an agile environment can avoid problems brought about by traditional software development, it turns out they are just bragging. The degree to which the software quality depends on the tester's quality and the manager's understanding of the test. I like the companies in the US, and call testers QA as quality assurance personnel. This is to inform testers that they should not only perform tests, but also participate in all activities related to product quality. They are responsible for product quality. In this way, the responsibilities and importance of testers will be greatly improved. Why? First, let's look at the software errors? Errors are introduced from the software requirement analysis. In addition, the more early errors occur, the greater the loss. Requirement analysis refers to converting users' requirements into product requirements. This is what system architects need to do. System architects need to clarify how this product meets user needs and use cases. These use cases are directly related to the test case of the system test in V-mode. The System Architect needs feedback from system testers to determine the testability and availability of the case. If users really need these cases, system testers often give their opinions. The Use Case deviation will directly lead to user dissatisfaction, and may lead to the failure of the entire feature. We have had a lot of such experiences, that is, the System Architect is easy to seek for perfection in the demand stage. In terms of the complexity of the system and the impact of new functions on the system, the system architect has no experience in how the customer uses the new feature, in the development and testing stages, the troubles keep increasing, so that the entire feature cannot be completed on schedule. When the final failure occurs, all the efforts are exhausted. When a system tester joins the demand stage, he can give feedback to the architect from the perspective of the user to tell him what functions are most needed and what functions are dispensable, where do users focus most. In this way, architects can make trade-offs to plan and optimize the parts that best meet the needs of users and are easy to implement and test, and discard those that are dispensable for users, it takes up a lot of development and testing time. Architects of a company are often trained by software developers. They pay too much attention to development costs, while ignoring test costs and users' experience. I remember a product manager once told me that it was difficult for them to get the real feelings of users, because they had a very limited meeting time with users, and they had one or two hours of meetings, we need to discuss dozens of new feature items. Each feature can only take 5 minutes. It is difficult to find out all the questions in these 5 minutes. You can only guess. In fact, a more effective way than guessing is to train excellent system testers. They are not only familiar with the test, but also understand the use of feature by verifying the bugs reported by users, as well as their feelings. Let system testers participate in the requirement analysis process to avoid large deviations from System Architects and help system architects predict how users use new feature, it is an important means to improve product quality. Then there is an error introduced by the software implementation. Software Implementation includes software design ideas, software architecture and code development. It corresponds to functional testing. Some people think that functional testing should be black box testing, focusing only on requirements, and not on software implementation. I think this sentence means that it should not be troubled by software implementation. However, this sentence is always correct. Sometimes, by understanding the software design philosophy, we can predict whether the software implementation meets the requirements, and avoid meaningless tests and waste valuable time. For example, we once had a feature of Dual-Backup interfaces. The design idea was very bad and the logic was chaotic. As long as we read the design documents, we knew the test results clearly. There is no need to perform the test again. The correct behavior should be "send back for Review", asking the software architect to reconsider the design method. But we still performed the test and found many problems. Then, the developer modified the bug and the result became messy. Finally, the developer did not know what was the correct action. This feature wastes a lot of time. There is also an example of IP QoS. After learning about the software solution, we know the test results. We believe that this does not meet the user's needs, but the test, error reporting, and error correction process did not achieve a good result. Whether the software design meets the requirements is the work of the software architect, and some companies work as senior software developers. If the software design cannot meet the requirements, the subsequent work will be in vain. Testing personnel participate in software design, not only to review the testability of the requirements, but also to view whether the design meets the product requirements from the testing and user perspective and to anticipate the testing results. This is very important for developers. There are also many problems with the introduction of software architecture. Experienced software architects know how to optimize the system, how to reduce the impact between modules, how interfaces are clearly defined and scalable, how data is shared and protected, and how messages are transmitted, how to increase the system capacity, allocate memory, recycle garbage, and select the simplest architecture based on these conditions while reducing system overhead. These statements are easy to talk about and difficult to do. In many cases, poor system architecture will introduce bottlenecks. With an understanding of the system architecture, testers can easily find out how to identify the most serious problems of the system. I remember when I went to a department to work as a test architect, the testers often asked me about this system problem. They had a strong feeling during the test, however, software architects have never known that they cannot hear the voices of testers. When I designed a few simple performance test cases and put the most direct test results in front of them, they seem to be waking up. However, at that time, it was impossible to modify the software architecture because it had entered the system testing stage. When the second version was developed, the architect wanted to modify the software architecture, but the cost was too high, so he had to make some limited adjustments. If experienced testers are involved in the software architecture, they are asked to help check the system architecture problems, rather than waiting for the test to know that a mistake has been made, it can greatly improve the quality of software. Maybe everyone is wondering why developers don't know what's wrong with their products? This is simple because developers are producers rather than users. Many software developers never use their own software except compiling their own software. In this way, they do not know whether the things they write are good or not. I remember writing the user interface when I first started working as a developer. At the beginning, I made a fancy job with a lot of functions, and I was proud of myself. But when I like to do it well, let the people next to me use it and listen to their opinions. As a result, they thought I was doing too well and it was not easy to use. I had to cut my foot and simplify the design. I kept making changes and making them use them, repeatedly and repeatedly. Finally, I removed all useless fancy things from their complaints, and the interface was clear and easy to use, even I like the final style. This is why Software Engineers cannot be testers of their own products at the same time. It is difficult for producers to objectively review and evaluate what they have created, so they are not as familiar with their products as users. During a long period of testing, the tester gradually learned about various problems in the software and system, and became more keen on possible problems. Architects may only need to spend half a day talking to testers to find out how big the things they have designed are. It is a pity that they often stand on top to listen to users' voices. After talking about this, I want to emphasize that it is important to improve the testing personnel's sense of responsibility and quality to improve the product quality. The sooner testers join the software development process, the more they can improve the quality of the software. Testers are not only testing executors, but also important participants in understanding requirements, reviewing requirement analysis, discussing software architecture, and looking for system bottlenecks. They are also user spokespersons. The requirements for testers are high, and the feedback and opinions of testers should be paid more attention. In many companies, testing is often the weakest link. We can see that there are many products in China with a lot of fancy functions, but they are very uncomfortable to use, and the quality is not very good. This is the result of focusing only on development and testing. If a company wants to develop in the long run, it must attach importance to testing, cultivate excellent testers, and give testers more responsibilities and rights to make their products more stable and easy to use, more in line with customer needs.

This article is from the "Debbie" blog, please be sure to keep this source http://debbie.blog.51cto.com/2754849/503195