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

The third realm of testing: challenge Zero defect

Confucius said, "if you have no foresight, you must have immediate worries." what does it mean when it is used in software testing? It can be understood that if we don't solve the problem from the root of the problem, think that testing is just looking for Bug, do everything possible to find Bug, and think that Bug is always endless, we will fall into a state of "never-ending". However, a small number of testers really wish there were more problems with the software, so that they could submit more Bug, thinking that the performance was definitely better than not submitting much Bug. Coincidentally, a small number of developers take their program errors for granted, and some even jokingly say, "if the software didn't have Bug, the testers would have lost their jobs." It's like singing an oboe. Bug is taken for granted throughout the process of software development, isn't it? Can the root cause of software crisis in software engineering be controlled only by finding Bug?

In fact, we all know that any Bug is generated from sources, including the design of requirements, the design of software (including code writing), and so on. Compared with the front-end design, testing is an ex post verification and a measure to "plug" loopholes. However, in practice, time and cost do not allow us to block all Bug. Japanese quality master Kenichi Taguchi said well that "quality is designed, not tested." If we can change from passive to active, we should take preventive measures before design to lay a solid foundation for the design of high-quality software. this is the third realm of testing that this section intends to introduce to readers: challenging zero defects.

Prevention and blocking of defects

Almost every time I interview a test engineer, I ask this question: "are there any omissions in the modules you have tested?" and almost every candidate replied "yes". In the face of complex software and complex running environment, it is impossible and unrealistic to achieve true zero bug in the testing activities carried out in a limited time. But these are not reasons. All testing activities are purposeful commercial activities, and each company has its own set of standards or principles for passing the test. Although missed detection is inevitable, it does not mean that missed detection is a normal phenomenon or should be a phenomenon. If the missed detection problem exceeds the principle acceptable to the company, it is an abnormal phenomenon, and it is necessary to carry out missed detection analysis. Carry out missed test analysis activities (it should be paid special attention to that it is by no means a criticism meeting for missing test personnel). Its main purpose is to find out the root cause of the problem by analyzing the lessons of the past, and to analyze which link of the test work is missing, in order to come up with evasive actionable measures.

When the tester carries on the missing test analysis, it is inevitable to trace the source of the problem. The software is designed by developers, so missed test analysis activities are not without the presence of developers, and sometimes even involve requirements designers. With regard to the origin of omission analysis, here is an interesting metaphor about the working relationship between development and testing, as shown in figure 2-11. Developers designing software is like building a dyke, if there is a structural problem with the dam, when the flood strikes, it may not only be a local leakage, but directly break the dike, like the collapse of the software. For high dams, it is inevitable that there will be small holes for leakage or small holes for seepage, just like small bugs in software. The more leaking or seepage problems are at the base of the dam, the more difficult it is to find them, and the greater the cost of solving them.

In the design to build a solid structure, there are no loopholes, of course, it is better, this is a kind of prevention. If you go beyond the prevention line and leave the large holes and small holes brought out by the design to the testing link, it has to take a variety of magnifying glasses (using various methods) to detect them, in order to catch all kinds of deep and shallow problems, large and small, and finally through the way of "patching" to plug the "hundreds of holes and sores" in the dyke.

In terms of defect prevention and blockage, testing is an intermediate role in finding problems, telling developers where they are leaking or leaking. The work of prevention and blockage is done by the builders of the dike. Of course, prevention is active, congestion is passive, after the initiative becomes passive, experienced the investment of resources and time, it is true that even if it is the same Bug, their costs are completely different. The later the blocking, the greater the impact, and the greater the cost, as shown in Table 2-6 (from the Code Book) is an example of increasing testing costs based on the stage at which the defect occurs.

Table 2: 6 the average cost of correcting the same defect based on the introduction and detection time of the defect

Lead-in time

Demand

Body-bound structure

Construction

Systematic test

After sending the cloth

Demand

one

three

5-10

ten

10: 100

System structure

--

one

ten

fifteen

250100

Construction

--

--

one

one

10: 25

A defect introduced during the requirements phase is shown in Table 2-6. If the problem is found immediately, the modification cost is only $1, but if it is found during the system test phase, the modification cost increases tenfold. To make matters worse, if the user finds this problem after the release of the version, it will cost more than 10 times or even 100 times the price. The longer the defect is in the system, the greater the cost of solving it, because the longer the time, the higher the cost of developers and testers to modify, and will affect a large area of client upgrades.

This article is excerpted from the book "Soul of Software testing: core Test Design (2nd Edition)"

By Xiao Liqiong

Published by Electronic Industry Press

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.