The third realm of testing: Challenges and zero defects

The third realm of testing: Challenges and zero defects

Confucius said that "people have no worries, they must have close concerns". What does it mean to use it for software testing? It can be understood that if we do not solve the problem from the root cause of the problem, we think that testing is just to findBug, Do everything possible to findBug, ThinkBugIf you can't find it, your consciousness will be in the state of "never every day. However, a small number of testers really want the software to have more problems (lest the world be messy), so that they can submit moreBugAnd the performance ratio is not submitted.BugDefinitely better. Coincidentally, a small number of developers have committed their ownProgramErrors are taken for granted. Some people may say, "if there is no softwareBugThe tester will not be unemployed ". It seems to be singing a double reed. During the entire process of software development,BugIt must exist, right? The root cause of software crisis in software engineering can only be foundBugIs it controlled?

In fact, we all know thatBugAll sources are generated, including the design of requirements and the design of software (includingCode. Compared with the front-end design, testing is post-event verification and a "blocking" vulnerability measure. However, in actual work, time and cost do not allow us to block allBug. Japanese quality Master Tian kouxuan said"Quality is designed, not tested". If we are able to change from passive to active, we should do a good job of designing preventive measures before design to lay a solid foundation for designing high-quality software, this is the third level of testing intended to be introduced to readers in this section: Challenge zero defects.

Prevention and Blocking of defects

Almost every time I interview a test engineer, I will ask the following question: "Is there any missed test in the modules you have tested ", almost every candidate answers "yes ". In the face of complex software and complex operating environments, test activities within a limited period of time to achieve real zeroBugIt is impossible and unrealistic. None of these are justification. All testing activities are purposeful commercial activities and each company has its own set of standards or principles that have been tested. Although the missed test is inevitable, it does not mean that the missed test is a normal phenomenon or a phenomenon. If the missed test problem exceeds the principle acceptable by the company, it is abnormal, it is necessary to conduct missed test analysis. Conduct the missed Test Analysis Activity (it is not an evaluation meeting for the missed testers). Its main purpose is to find out the root cause of the problem by analyzing the lessons learned from the past, analyze which part of the test is missing to take feasible preventive measures.

When testers conduct missed tests and analyses, they will inevitably trace the source of the problem. The software is designed by developers, so the missed test and analysis activities are indispensable for the presence of developers, and sometimes involve the demand designers. Here is an interesting analogy about the working relationship between development and testing, like building a dam,2? 11. Developers design software like building a dam. If the dam has structural problems, when the flood strikes, it may not only leak locally, but directly decide the dike, as if the software crashes. A high dam may inevitably have a small hole in water leakage, or a small hole in water seepage. It is like a small hole in the software.Bug. The more water leakage or seepage problems at the base of the dam, the more difficult it is to find out, the more costly it is to solve.

The structure should be fixed during the design. It is certainly better if no vulnerability exists. This is a precaution. If it goes beyond the defense line and leaves the large holes in the design to the test link, it has to take a variety of magnifiers (using a variety of methods) for detection, in order to collect a variety of deep, small and small problems, at last, we used patches to block the "-bit sore" on the dam ".

In the aspect of prevention and blocking of defects, testing is the intermediate role for discovering problems, telling developers where water leaks or water seepage occurs. Defense and blocking are implemented by the dike builders. Of course, anti-DDoS is active and blocking is passive. After the active mode becomes passive, resources and time are invested in the middle. It is true that even the sameBugAnd their costs are completely different. The greater the impact, the higher the cost, such as the table2-6As shown in the code book, this is an example of increasing the testing cost based on the fault occurrence stage.

Table2?6The average cost required to correct the same Defect Based on the defect introduction and detection time

Import time		body structure	set	system test	after release
requirements	1	3	5 ~ 10	10	10 ~ 100
architecture	--	1	10	15	25 ~ 100
construction	--	--	1	1	10 ~ 25

Such as table2-6Shows a defect introduced in the demand phase. If this problem is detected immediately, you only need to modify the cost1USD, but if it is found in the system test phase, the modification cost will increase.10Times. More seriously, if the user finds this problem after the version is released, you need to pay10Times or more100Cost. The longer the defect takes in the system, the higher the cost of solving it. Because the longer the time, the higher the cost for developers and testers to modify the defect, which will also affect the large-scale upgrade of the client.

 

 

This article is excerpted from the soul of software testing: the essence of Core Test Design (2(Version)

Xiao liqiongBy

published by the Electronic Industry Publishing House