by Li Cuifang Testing Engineer
At the bottom of the R & D ecological chain, testing engineers have endless knowledge to learn and endless bugs to report. After years of in-line testing, I summarize the following feelings and understandings to see if you feel the same way.
Although it has been recognized that software quality has become the core competitiveness of software. From the customer’s point of view, software quality is far more important than function. Our software test engineers as the software “check-in “, but also the quality of the software” gatekeeper “, we’ve become what many R & D professionals call the “no technology content, just the dot function .” But it has to be said that testing is really more than a simple dot. From requirements analysis to use case writing, to test methods at different testing stages, the use of various testing tools and the knowledge are required by testers and their importance cannot be underestimated.
In everyone’s view, testing is a job of low technical skills that do not have too much science and engineering knowledge reserves. Simple functional test execution may just take care and patience to get the job done. But if we really want to do a good job of testing, we need to constantly learn new technology, new testing methods and tools. To improve efficiency, we will consider new testing methods, such as automation; we will learn to use a lot of testing tools, Zen Tao, Postman、QTP、LR、Jemeter、SVN、UL and so on.
Testing engineers should find as many defects as possible and improve the reliability of the software. But because of the project cost, the test cycle and the changeable running environment of the software, it is impossible to run the test by exhaustive method except small system. So through risk analysis, test point priority analysis to determine the test concerns. In the use case design, we also use the corresponding design techniques, such as boundary value, equivalence class partition and so on. Also for software defects, even if the project is successfully delivered, it does not mean that our system is free of any defects. We can only find as many effective, user-aware defects as possible in a limited time.
As a team, we and R & D personnel have a common goal, that is to make products meet customer satisfaction. But because of their roles and different perspectives, R & D and testers often disagree on the bugs. R & D think it’s not a problem that should not be fixed, but testers insist it needs to be fixed. This often happens, and in the event of a standoff, consideration needs to be given to requesting the project manager or to drawing on multiple meetings to decide whether a solution is needed.
As the “checker” of software, test is the “gatekeeper” of software quality. When there is a problem with the system or the customer feedback, many people’s first reaction is that the tester missed the test and did not test in place. It is also a grievance for testers, who, although they are the last line of defense for software quality, as mentioned above, cannot exhaust all defects, and can only find as many as possible to ensure the quality of the product. But we will always strive to deliver products that satisfy our customers. Stable product launch, customer satisfaction is our most proud thing.
Early involvement in testing is a fundamental tenet of software advocacy. Multiple studies have shown that most defects are introduced during the requirements phase, but are discovered during the system test phase. However, the defects in the early stage will be continuously enlarged with the development stage, and the later the defect is found, the higher the cost of defect repair will be. Therefore, early test intervention, early detection of defects, and good review activities are a very good means. In addition, testers should learn and study the development products as early as possible, which is conducive to the design and execution of test cases, and better carry out test activities and complete test tasks.
Having said so much, do you feel the same way? There are a lot of pain points, we firmly believe that ridicule is also a process of reflection and seeking for progress, we will still be painful and happy on the road ahead of the test.